On Wed, Jul 18, 2018 at 09:42:18AM +0100, Patrick Bellasi wrote: > On 17-Jul 10:50, Joel Fernandes wrote: > > On Mon, Jul 16, 2018 at 09:28:55AM +0100, Patrick Bellasi wrote: > > [...] > > > > diff --git a/init/Kconfig b/init/Kconfig > > > index 041f3a022122..1d45a6877d6f 100644 > > > --- a/init/Kconfig > > > +++ b/init/Kconfig > > > @@ -583,6 +583,25 @@ config HAVE_UNSTABLE_SCHED_CLOCK > > > config GENERIC_SCHED_CLOCK > > > bool > > > > > > +menu "Scheduler features" > > > + > > > +config UCLAMP_TASK > > > + bool "Enable utilization clamping for RT/FAIR tasks" > > > + depends on CPU_FREQ_GOV_SCHEDUTIL > > > > Does it make sense to depend on this? One could turn off schedutil and then > > uclamp can't be used for any other purpose (big.LITTLE task placement etc)? > > You right, utilization clamping is _going_ to target tasks placement. > But, the support currently posted in this series is just for OPP > biasing. Thus, it would not make sense to enabled it when schedutil > is not available. > > My idea was to keep this dependency while we finalize these bits. > Once we move on to the tasks placement biasing, we will remove this > dependency too. > > Does that makes sense?
Yes, that's fine with me.
