On 06/24/20 13:35, Joel Fernandes wrote: [...]
> > 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. The series is an optimization to remove the uclamp overhead from the scheduler fastpath until the userspace uses it. It introduces a static key that is disabled by default and will cause uclamp logic not to execute in the fast path. Once the userspace starts using util clamp, which we detect by either 1. Changing uclamp value of a task with sched_setattr() 2. Modifying the default sysctl_sched_util_clamp_{min, max} 3. Modifying the default cpu.uclamp.{min, max} value in cgroup If we start having in-kernel users changing uclamp value this means drivers will cause the system to opt-in into uclamp automatically even if the userspace doesn't actually use it. I think we can solve this by providing a special API to opt-out safely. Which is the right thing to do anyway even if we didn't have this clash. Hope this makes sense. Cheers -- Qais Yousef
