linux-kernel - Re: [PATCH 1/2] sched/uclamp: Add a new sysctl to control RT default boost value

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 28 May 2020 18:11:12 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Qais Yousef <qais.yousef@....com>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Jonathan Corbet <corbet@....net>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Iurii Zaikin <yzaikin@...gle.com>,
        Quentin Perret <qperret@...gle.com>,
        Valentin Schneider <valentin.schneider@....com>,
        Patrick Bellasi <patrick.bellasi@...bug.net>,
        Pavan Kondeti <pkondeti@...eaurora.org>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 1/2] sched/uclamp: Add a new sysctl to control RT default
 boost value

On Thu, May 28, 2020 at 04:58:01PM +0100, Qais Yousef wrote:
> On 05/28/20 15:23, Peter Zijlstra wrote:

> > So afaict this is directly added to the enqueue/dequeue path, and we've
> > recently already had complaints that uclamp is too slow.
> 
> I wanted to keep this function simpler.

Right; I appreciate that, but as always it's a balance between simple
and performance :-)

> > Is there really no other way?
> 
> There is my first attempt which performs the sync @ task_woken_rt().
> 
> https://lore.kernel.org/lkml/20191220164838.31619-1-qais.yousef@arm.com/
> 
> I can revert the sync function to the simpler version defined in that patch
> too.
> 
> I can potentially move this to uclamp_eff_value() too. Will need to think more
> if this is enough. If task_woken_rt() is good for you, I'd say that's more
> obviously correct and better to go with it.

task_woken_rt() is better, because that only slows down RT tasks, but
I'm thinking we can do even better by simply setting the default such
that new tasks pick it up and then (rcu) iterating all existing tasks
and modiying them.

It's more code, but it is all outside of the normal paths where we care
about performance.

> FWIW, I think you're referring to Mel's notice in OSPM regarding the overhead.
> Trying to see what goes on in there.

Indeed, that one. The fact that regular distros cannot enable this
feature due to performance overhead is unfortunate. It means there is a
lot less potential for this stuff.