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

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]?

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center