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

[Philippe Gerum <rpm@xenomai.org>]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 20.06.26 14:40, Jan Kiszka wrote:
>> On 20.06.26 13:17, Philippe Gerum wrote:
>>> Philippe Gerum <rpm@xenomai.org> writes:
>>>
>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>
>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>
>>>>> 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.

-- 
Philippe.