linux-kernel - Re: [PATCH 00/14] Modularize schedutil

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]

Message-ID: <CAJZ5v0iaa_VCtN608QKTYZ-A6QG_7bwxihxSgoEGv1LcSK-ksA@mail.gmail.com>
Date:   Fri, 8 May 2020 15:40:34 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Quentin Perret <qperret@...gle.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Sudeep Holla <sudeep.holla@....com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>, bsegall@...gle.com,
        Mel Gorman <mgorman@...e.de>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Kees Cook <keescook@...omium.org>, yzaikin@...gle.com,
        Frederic Weisbecker <fweisbec@...il.com>,
        Todd Kjos <tkjos@...gle.com>,
        "Cc: Android Kernel" <kernel-team@...roid.com>
Subject: Re: [PATCH 00/14] Modularize schedutil

On Fri, May 8, 2020 at 3:05 PM Quentin Perret <qperret@...gle.com> wrote:
>
> On Friday 08 May 2020 at 13:31:41 (+0200), Peter Zijlstra wrote:
> > On Fri, May 08, 2020 at 12:16:12PM +0100, Quentin Perret wrote:
> > > However, the point I tried to make here is orthogonal to that. As of
> > > today using another governor than schedutil is fully supported upstream,
> > > and in fact it isn't even enabled by default for most archs. If vendors
> > > feel like using something else makes their product better, then I don't
> > > see why I need to argue with them about that. And frankly I don't see
> > > that support being removed from upstream any time soon.
> >
> > Right, it'll take a while to get there. But that doesn't mean we
> > shouldn't encourage schedutil usage wherever and whenever possible. That
> > includes not making it easier to not use it.
> >
> > In that respect making it modular goes against our ultimate goal (world
> > domination, <mad giggles here>).
>
> Right, I definitely understand the sentiment. OTOH, things like that
> give vendors weapons against GKI ('you-force-us-to-build-in-things-we-dont't-want'
> etc etc). That _is_ true to some extent, but it's important we make sure
> to keep this to an absolute minimum, otherwise GKI just won't happen
> (and I really think that'd be a shame, GKI _is_ a good thing for
> upstream).
>
> And sure, schedutil isn't that big, and we can make an exception. But
> I'm sure you know what happens when you starting making exceptions ;)

This is a very weak argument, if it can be regarded as an argument at all.

You will have to make exceptions, the question is how many and on what
criteria and you really need to figure that out for the GKI plan.

> So, all in all, I don't think the series actively makes schedutil worse
> by adding out-of-line calls in the hot path or anything like that, and
> having it as a module helps with GKI which I'm arguing is a good thing
> in the grand scheme of things.

Frankly, I'm not sure if it really helps.

The idea of making schedutil modular seems to be based on the
observation that it is not part of the core kernel, which I don't
agree with.  Arguably, things like util clamps need it to work as
expected.

> That of course is only true if we can
> agree on a reasonable set of exported symbols, so I'll give others some
> time to complain and see if I can post a v2 addressing these issues!

This isn't just about exported symbols, it is about what is regarded
as essential and what isn't.

Cheers!