libevl: sched-quota test lacks success check

libevl: sched-quota test lacks success check

[Jan Kiszka]

Hi Philippe,

trying to port the sched-quota fixes back to xenomai 3, I had a look at
again at the libevl test. And since [1], it always succeeds (unless some
function returns an error), no more checking of percentage boundaries.
That's not helpful for CI, though. Would it make sense to re-introduce
this, just with an exception for VM hosts? That what we do in xenomai3.

Jan

[1]
https://gitlab.com/Xenomai/xenomai4/libevl/-/commit/22ed65d951dd49b159e52c498dda49b2492138f7

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: libevl: sched-quota test lacks success check

[Jan Kiszka]

On 31.08.26 14:48, Jan Kiszka wrote:
> Hi Philippe,
> 
> trying to port the sched-quota fixes back to xenomai 3, I had a look at
> again at the libevl test. And since [1], it always succeeds (unless some
> function returns an error), no more checking of percentage boundaries.
> That's not helpful for CI, though. Would it make sense to re-introduce
> this, just with an exception for VM hosts? That what we do in xenomai3.
> 

But first of all, we need to fix the reworked calibration of this test -
it happens already under quota conditions... Patch under preparation.

Jan

> Jan
> 
> [1]
> https://gitlab.com/Xenomai/xenomai4/libevl/-/commit/22ed65d951dd49b159e52c498dda49b2492138f7
> 

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: libevl: sched-quota test lacks success check

[Philippe Gerum]

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

> Hi Philippe,
>
> trying to port the sched-quota fixes back to xenomai 3, I had a look at
> again at the libevl test. And since [1], it always succeeds (unless some
> function returns an error), no more checking of percentage boundaries.
> That's not helpful for CI, though. Would it make sense to re-introduce
> this, just with an exception for VM hosts? That what we do in xenomai3.
>
> Jan
>
> [1]
> https://gitlab.com/Xenomai/xenomai4/libevl/-/commit/22ed65d951dd49b159e52c498dda49b2492138f7

Yes, I'd be fine with that, although the acceptable score could be
arguably different even across hw platforms, so we would have to pick a
conservative value to declare success/failure unless the test adapts
based on some heuristics. This said, I agree that running_on_vm() is our
friend to fully disable such check only on VM since the figure does not
make much sense there.

-- 
Philippe.