linux-kernel - Re: [PATCH v4 4/8] sched/core: Add permission checks for setting the latency

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 20 Sep 2022 16:56:50 +0200
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Tim Janik <timj@....org>
Cc:     mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com,
        dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
        mgorman@...e.de, bristot@...hat.com, vschneid@...hat.com,
        linux-kernel@...r.kernel.org, parth@...ux.ibm.com,
        qais.yousef@....com, chris.hyser@...cle.com,
        valentin.schneider@....com, patrick.bellasi@...bug.net,
        David.Laight@...lab.com, pjt@...gle.com, pavel@....cz,
        tj@...nel.org, qperret@...gle.com, tim.c.chen@...ux.intel.com,
        joshdon@...gle.com
Subject: Re: [PATCH v4 4/8] sched/core: Add permission checks for setting the
 latency_nice value

On Tue, 20 Sept 2022 at 12:18, Tim Janik <timj@....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/