linux-kernel - Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

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: <CAJWu+ooXdgqSGisZXnHBtYLo9oQBiaNR=HhKseBN+YFGz-L6Xg@mail.gmail.com>
Date:   Wed, 24 Jun 2020 11:49:44 -0400
From:   Joel Fernandes <joelaf@...gle.com>
To:     Qais Yousef <qais.yousef@....com>
Cc:     Doug Anderson <dianders@...omium.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Benson Leung <bleung@...omium.org>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        hsinyi@...omium.org, Nicolas Boichat <drinkcat@...omium.org>,
        Gwendal Grignou <gwendal@...omium.org>,
        Quentin Perret <qperret@...gle.com>, ctheegal@...eaurora.org,
        Guenter Roeck <groeck@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump
 cpu freq

On Tue, Jun 23, 2020 at 12:40 PM Qais Yousef <qais.yousef@....com> wrote:
>
> On 06/22/20 11:21, Doug Anderson wrote:
>
> [...]
>
> > > If you propose something that will help the discussion. I think based on the
> > > same approach Peter has taken to prevent random RT priorities. In uclamp case
> > > I think we just want to allow driver to opt RT tasks out of the default
> > > boosting behavior.
> > >
> > > I'm a bit wary that this extra layer of tuning might create a confusion, but
> > > I can't reason about why is it bad for a driver to say I don't want my RT task
> > > to be boosted too.
> >
> > Right.  I was basically just trying to say "turn my boosting off".
> >
> > ...so I guess you're saying that doing a v2 of my patch with the
> > proper #ifdef protection wouldn't be a good way to go and I'd need to
> > propose some sort of API for this?
>
> It's up to Peter really.
>
> It concerns me in general to start having in-kernel users of uclamp that might
> end up setting random values (like we ended having random RT priorities), that
> really don't mean a lot outside the context of the specific system it was
> tested on. Given the kernel could run anywhere, it's hard to rationalize what's
> okay or not.
>
> Opting out of default RT boost for a specific task in the kernel, could make
> sense though it still concerns me for the same reasons. Is this okay for all
> possible systems this can run on?
>
> It feels better for userspace to turn RT boosting off for all tasks if you know
> your system is powerful, or use the per task API to switch off boosting for the
> tasks you know they don't need it.
>
> But if we want to allow in-kernel users, IMO it needs to be done in
> a controlled way, in a similar manner Peter changed how RT priority can be set
> in the kernel.
>
> It would be good hear what Peter thinks.

It seems a bit of a hack, but really the commit message says the
driver is not expected to take a lot of CPU capacity so it should be
expected to work across platforms. It is likely to behave better than
how it behaves now.