Re: [PATCH v4 4/8] sched/core: Add permission checks for setting the latency_nice value

[Vincent Guittot <vincent.guittot@linaro.org>]

On Tue, 20 Sept 2022 at 12:18, Tim Janik <timj@gnu.org> wrote:
>
> Hi.
>
> On 19.09.22 14:41, Vincent Guittot wrote:
> > Hi,
> >
> > Thanks you for describing in detail your use case.
>
> > Ok, Your explanation makes sense to me especially because we want to
> > ensure to not provide more cpu time with this latency prio. I'm
> > curious to see the feedback from others about the reason we want
> > CAP_SYS_NICE other than following nice priority.
> >
> > Side question, Have you tried this patchset (minus this patch) with
> > your use case ?
>
> I have now tested a modified version of the ALSA Test_latency.c program
> that acquires latency nice as non-root:
>    https://gist.github.com/tim-janik/88f9df5456b879ecc59da93dc6ce6be1
>
> With a busy but not overloaded CPU, the short time latency tests are
> often better, measured with: ./lnice-latency -p -s 1
>
> But the results aren't very reliable with this test. I.e. requesting a
> latency nice value of -20 reduces the chance for underruns somewhat but
> doesn't eliminate them (and lnice-latency.c gives up on the first XRUN

It's expected that latency nice can't fix all scheduling latency
problems. The hard real time constraint can only be ensured with FIFO
or deadline scheduler

> in the given time period). It might be better to instead count the XRUN
> occurances over a given time pertiod.

Thanks. I'm going to have a look the test

>
>
> --
> Anklang Free Software DAW
> https://anklang.testbit.eu/