Messages in this thread | | | From | Joel Fernandes <> | Date | Wed, 24 Jun 2020 13:55:02 -0400 | Subject | Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq |
| |
On Wed, Jun 24, 2020 at 1:52 PM Qais Yousef <qais.yousef@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.yousef@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
| |