Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200610151818.1.I666ecd9c6f3c6405bd75831a21001b8109b6438c@changeid>
 <20200612125250.7bwjfnxhurdf5bwj@e107158-lin.cambridge.arm.com>
 <CAD=FV=WuYZRO=sv4ODr0SFk0gTtvCW0dNQXbFGrBDqRgjYv-jA@mail.gmail.com>
 <20200619153851.vigshoae3ahiy63x@e107158-lin.cambridge.arm.com>
 <CAD=FV=XursDFUWL=aGUwFgXc4BugUMdT5e+Fwwo5w2gReCjUaQ@mail.gmail.com>
 <20200623164021.lcrnwpli7wdlsn5i@e107158-lin.cambridge.arm.com>
 <CAJWu+ooXdgqSGisZXnHBtYLo9oQBiaNR=HhKseBN+YFGz-L6Xg@mail.gmail.com> <20200624165500.idrugfgplqgi654v@e107158-lin.cambridge.arm.com>
In-Reply-To: <20200624165500.idrugfgplqgi654v@e107158-lin.cambridge.arm.com>
From:   Joel Fernandes <joelaf@google.com>
Date:   Wed, 24 Jun 2020 13:35:28 -0400
Message-ID: <CAJWu+oqHUq6fvkfRgAx4qx8x1dm-J-h6moeVskCU3gkRybCPqQ@mail.gmail.com>
Subject: Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump
 cpu freq
To:     Qais Yousef <qais.yousef@arm.com>
Cc:     Doug Anderson <dianders@chromium.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Benson Leung <bleung@chromium.org>,
        Enric Balletbo i Serra <enric.balletbo@collabora.com>,
        hsinyi@chromium.org, Nicolas Boichat <drinkcat@chromium.org>,
        Gwendal Grignou <gwendal@chromium.org>,
        Quentin Perret <qperret@google.com>, ctheegal@codeaurora.org,
        Guenter Roeck <groeck@chromium.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Jun 24, 2020 at 12:55 PM Qais Yousef <qais.yousef@arm.com> wrote:
>
> On 06/24/20 11:49, Joel Fernandes wrote:
> > On Tue, Jun 23, 2020 at 12:40 PM Qais Yousef <qais.yousef@arm.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
>
> Which part is the hack, the userspace control? It is how Linux expects things
> to work AFAIU. But I do agree there's a hole for general purpose userspace that
> wants to run and manage a diverse range of hardware.

I meant to say, this patch is a necessary hack of sorts.

> > 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.
>
> Doing the in-kernel opt-out via API should be fine, I think. But this will
> need to be discussed in the wider circle. It will already clash with this for
> example
>
> https://lore.kernel.org/lkml/20200619172011.5810-1-qais.yousef@arm.com/

Have not yet looked closer at that patch, but are you saying this
patch clashes with that work? Sorry I am operating on 2 hours of sleep
here.