Re: [libevl][PATCH 2/2] tests: sched-quota-accuracy: Add preempting FIFO thread

Philippe Gerum <[email protected]> writes:

> Jan Kiszka <[email protected]> writes:
>
>> On 20.06.26 14:40, Jan Kiszka wrote:
>>> On 20.06.26 13:17, Philippe Gerum wrote:
>>>> Philippe Gerum <[email protected]> writes:
>>>>
>>>>> Jan Kiszka <[email protected]> writes:
>>>>>
>>>>>> From: Jan Kiszka <[email protected]>
>>>>>>
>>>>>> Test that higher-prio SCHED_FIFO threads do not run on the bill of
>>>>>> SCHED_QUOTA threads and that their accounting is not otherwise
>>>>>> disturbed.
>>>>>>
>>>>>
>>>>> This patch introduced a regression when determining the accuracy of the
>>>>> policy with respect to allotting threads the expected runtime budget:
>>>>>
>>>>> root@phytec-mira-evl:~# evl test sched-quota-accuracy
>>>>> sched-quota-accuracy: 494.0%
>>>>>
>>>>> The proper result would rather be close to the following:
>>>>>
>>>>> root@phytec-mira-evl:~# evl test sched-quota-accuracy
>>>>> sched-quota-accuracy: 99.1%
>>>>
>>>> Ok, I guess the fact that the calibration process does not factor in the
>>>> disruptor explains the full breakage we have with the accounting now:
>>>>
>>>> root@phytec-mira-evl:~# evl test sched-quota-accuracy -- -v
>>>> picked CPU1 for execution
>>>> CPU1: calibrating: 893547 loops/sec
>>>> CPU1: new thread group #0, quota sum is 10%
>>>> CPU1: done quota_thread[0], count=150399
>>>> CPU1: done quota_thread[1], count=145636
>>>> CPU1: done quota_thread[2], count=141552
>>>> CPU1: 3 threads: cap=10%, effective=49.0%, disruption=49.6%
>>>> sched-quota-accuracy: 489.7%
>>>>
>>>> Which does not make any sense since the effective value should be capped
>>>> at 10% in the above case, compared to the nominal (full) report which
>>>> should be:
>>>>
>>>> root@phytec-mira-evl:~# evl test sched-quota-accuracy -- -v
>>>> picked CPU1 for execution
>>>> CPU1: calibrating: 899203 loops/sec
>>>> CPU1: new thread group #0, quota sum is 10%
>>>> CPU1: done quota_thread[0], count=26818
>>>> CPU1: done quota_thread[1], count=26709
>>>> CPU1: done quota_thread[2], count=35612
>>>> CPU1: 3 threads: cap=10%, effective=9.9%
>>>> sched-quota-accuracy: 99.1%
>>>>
>>>> Dropping this patch from the -next branch for now.
>>>>
>>> 
>>> I would rather recommend taking a trace and debugging the scheduler -
>>> this could very likely be remaining issue in the quota fix.
>>> 
>>
>> What is the state of this? How can I reproduce the issue you saw? What
>> is specific to the target, what could also be seen over qemu[/kvm]?
>>
>
> The task of writing a proper test for evl is ongoing, the overall sched
> issue is very much on my radar. I'll follow up when this test code is
> available.

You need to pick e5e876da..3e32fa6f from [1] for the kernel bits, and
198a21b7..HEAD from [2] for an improved sched-quota-accuracy test which
also measures the preemption noise, with a significantly simpler
implementation. The topmost commits in [2] also introduce an interface
to the ftrace-based 'evl_trace' event which I used for debugging.

Basically, I merged the gist of our past proposals, refining here and
there as issues were uncovered.

Heavily tested on real hardware, which uncovered a couple of other
serious issues. I plan to write a separate test program for testing the
runtime credit and peak management.

[1]
https://gitlab.com/Xenomai/xenomai4/linux-evl/-/commits/next/v6.12.y-cip-evl-rebase?ref_type=heads

[2] https://gitlab.com/Xenomai/xenomai4/libevl/-/commits/next?ref_type=heads

-- 
Philippe.