Messages in this thread | | | Date | Wed, 24 Jun 2020 18:01:09 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq |
| |
On Tue, Jun 23, 2020 at 05:40:21PM +0100, Qais Yousef 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.
Hurmph.. I think I understand the problem, but I'm not sure what to do about it :-(
Esp. given the uclamp optimization patches now under consideration. That is, if random drivers are going to install uclamps, then that will automagically enable the static_key and make the scheduler slower, even if that driver isn't particularly interesting to the user.
| |