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

[Qais Yousef]

On 06/24/20 11:49, Joel Fernandes wrote:
> On Tue, Jun 23, 2020 at 12:40 PM Qais Yousef <qais.yousef@xxxxxxx> 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 still think it's the job of device manufacturers/system integrator. But
not many ship Linux by default. Though I thought ChromeOS is the exception
here.

> 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@xxxxxxx/

Thanks

--
Qais Yousef