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

[Philippe Gerum <rpm@xenomai.org>]

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.

-- 
Philippe.