On Wed, Jun 24, 2020 at 1:52 PM Qais Yousef <qais.you...@arm.com> wrote: > > 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.
Makes sense, thanks. - Joel
