Re: [LTP] [PATCH v3] cfs-scheduler/starvation.c: Skip test on realtime kernels

[Petr Vorel <pvorel@suse.cz>]

> Hi Petr,

> Thanks for the feedback.

> On Mon, Jan 27, 2025 at 10:39 AM Petr Vorel <pvorel@suse.cz> wrote:

> > > This commit introduces a check in the starvation test case to detect and
> > > skip execution on realtime kernels. The test is designed for use with the
> > > Completely Fair Scheduler and produces meaningless results when run on
> > > realtime kernels.

> > > By skipping the test on realtime kernels, we avoid confusion caused by
> > > misleading results.

> > Thanks a lot for fixing -1 in v3. I was thinking to merge v2 and fix -1
> > manually, but I'm really not sure if the test is meaningless for realtime.
> > Was the test really written for CFS? It would be nice to get ack from any
> > realtime developer.

> > BTW test is working well on x86_64 SLES realtime kernel on VM, i.e. both you
> > want to skip (RT) or warn about unreliable results (VM). That of course
> > does not mean it's relevant for RT kernel.

> Here's what I observed:
> * In our CI pipeline, the test consistently fails on our RT kernel running
>   on AARCH64 boards.
> * Upon investigating and reading through the code, I noticed that the test
>   seems to rely on an equal number of times the child and parent tasks get
>   scheduled. This behavior aligns with how CFS works... less with RT.
> * That said, there are scenarios where CFS and RT might make similar
>   scheduling decisions, particularly in RT when all tasks share the same
>   priority.
> * Finally, as a hint, I noticed that the test is currently placed in the
>   cfs-scheduler directory. I interpret this as a strong suggestion from the
>   author that the test was intended for the CFS scheduler.

Oops, I completely missed the directory. And all the above sounds right.
Also reproducer was posted for EEVDF, which is CFS replacement.

OTOH cfs_bandwidth01.c, which requires CONFIG_CFS_BANDWIDTH works on RT kernel
well, also very old hackbench.c (which needs to be rewritten).

Anyway I wanted to have ack of somebody who actually understands the kernel
code. I got a confirmation from Mike Galbraith that "the test is about fair class
vs fair class wakeup latency, has little relevance to RT. It does bang on locks
in the wakeup path, but no more than about a zillion other things." therefore
I'm going to merge.

Kind regards,
Petr

> > Kind regards,
> > Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp