lkml.org 
[lkml]   [2020]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq
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.

Thanks

--
Qais Yousef

\
 
 \ /
  Last update: 2020-06-23 18:41    [W:1.258 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site