On Wed, Jun 24, 2020 at 12:55 PM Qais Yousef <qais.you...@arm.com> wrote: > > On 06/24/20 11:49, Joel Fernandes wrote: > > On Tue, Jun 23, 2020 at 12:40 PM Qais Yousef <qais.you...@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.you...@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.
