| Message ID | 20180912091309.7551-6-quentin.perret@arm.com (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | Energy Aware Scheduling | expand |
On Wed, Sep 12, 2018 at 10:13:00AM +0100, Quentin Perret wrote: > In order to make sure Energy Aware Scheduling (EAS) doesn't hurt > systems not using it, add a new sched_feat, called ENERGY_AWARE, > guarding the access to EAS code paths. > > Signed-off-by: Quentin Perret <quentin.perret@arm.com> > --- > kernel/sched/features.h | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/kernel/sched/features.h b/kernel/sched/features.h > index 85ae8488039c..26ff6752e492 100644 > --- a/kernel/sched/features.h > +++ b/kernel/sched/features.h > @@ -90,3 +90,10 @@ SCHED_FEAT(WA_BIAS, true) > * UtilEstimation. Use estimated CPU utilization. > */ > SCHED_FEAT(UTIL_EST, true) > + > +/* > + * Energy-Aware Scheduling. Whether or not tasks will be placed into an > + * energy-aware fashion depends on this feature being enabled and on the > + * root domain having an Energy Model attached. > + */ > +SCHED_FEAT(ENERGY_AWARE, false) So these are debug knobs.. I would expect there to be a regular static_key that is controlled by the presence of EM data. Remember, if you compile with SCHED_DEBUG=n, this becomes a compile time constant: false, and the compiler gets to do lots of DCE.
On Tuesday 02 Oct 2018 at 14:34:16 (+0200), Peter Zijlstra wrote: > On Wed, Sep 12, 2018 at 10:13:00AM +0100, Quentin Perret wrote: > > In order to make sure Energy Aware Scheduling (EAS) doesn't hurt > > systems not using it, add a new sched_feat, called ENERGY_AWARE, > > guarding the access to EAS code paths. > > > > Signed-off-by: Quentin Perret <quentin.perret@arm.com> > > --- > > kernel/sched/features.h | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/kernel/sched/features.h b/kernel/sched/features.h > > index 85ae8488039c..26ff6752e492 100644 > > --- a/kernel/sched/features.h > > +++ b/kernel/sched/features.h > > @@ -90,3 +90,10 @@ SCHED_FEAT(WA_BIAS, true) > > * UtilEstimation. Use estimated CPU utilization. > > */ > > SCHED_FEAT(UTIL_EST, true) > > + > > +/* > > + * Energy-Aware Scheduling. Whether or not tasks will be placed into an > > + * energy-aware fashion depends on this feature being enabled and on the > > + * root domain having an Energy Model attached. > > + */ > > +SCHED_FEAT(ENERGY_AWARE, false) > > So these are debug knobs.. I would expect there to be a regular > static_key that is controlled by the presence of EM data. Right, the issue I'm trying to solve with this is basically that _some_ users will want to have an EM for the thermal stuff, but they will want EAS disabled. Some people (not very many that's true, but still) use big.little and don't care much about energy ... So, there is a need for an EAS knob on the scheduler side. I don't mind it being something else than a sched_feat, but I couldn't see a better option. Another Kconfig (CONFIG_SCHED_ENERGY) ? A sysctl ? FWIW, the Android kernel has had an ENERGY_AWARE sched_feat since the very beginning of EAS. > Remember, if you compile with SCHED_DEBUG=n, this becomes a compile time > constant: false, and the compiler gets to do lots of DCE. Indeed, and what happens in the mobile market sometimes is that people play with those options as needed and then they put patches in their device kernels to change the defaults before compiling with !SCHED_DEBUG. I'd say it's not the worst kind of device-specific out-of-tree changes to Linux. That's debatable however Thanks, Quentin
On Tue, Oct 02, 2018 at 02:08:21PM +0100, Quentin Perret wrote: > On Tuesday 02 Oct 2018 at 14:34:16 (+0200), Peter Zijlstra wrote: > > So these are debug knobs.. I would expect there to be a regular > > static_key that is controlled by the presence of EM data. > > Right, the issue I'm trying to solve with this is basically that _some_ > users will want to have an EM for the thermal stuff, but they will want > EAS disabled. Some people (not very many that's true, but still) use > big.little and don't care much about energy ... > > So, there is a need for an EAS knob on the scheduler side. I don't mind > it being something else than a sched_feat, but I couldn't see a better > option. Another Kconfig (CONFIG_SCHED_ENERGY) ? A sysctl ? Yeah, sysctl, see for example: sysctl.kernel.numa_balancing and the sched_numa_balancing static_key that goes with it. I would default enable EAS if the EM is there and valid, but allow people to disable it.
On Wednesday 03 Oct 2018 at 18:24:35 (+0200), Peter Zijlstra wrote: > Yeah, sysctl, see for example: sysctl.kernel.numa_balancing and the > sched_numa_balancing static_key that goes with it. OK, that works for me. > I would default enable EAS if the EM is there and valid, but allow > people to disable it. Right, that'd be much nicer than the sched_feat off by default, I agree. I'll see what I can do :-) Thanks, Quentin
diff --git a/kernel/sched/features.h b/kernel/sched/features.h index 85ae8488039c..26ff6752e492 100644 --- a/kernel/sched/features.h +++ b/kernel/sched/features.h @@ -90,3 +90,10 @@ SCHED_FEAT(WA_BIAS, true) * UtilEstimation. Use estimated CPU utilization. */ SCHED_FEAT(UTIL_EST, true) + +/* + * Energy-Aware Scheduling. Whether or not tasks will be placed into an + * energy-aware fashion depends on this feature being enabled and on the + * root domain having an Energy Model attached. + */ +SCHED_FEAT(ENERGY_AWARE, false)
In order to make sure Energy Aware Scheduling (EAS) doesn't hurt systems not using it, add a new sched_feat, called ENERGY_AWARE, guarding the access to EAS code paths. Signed-off-by: Quentin Perret <quentin.perret@arm.com> --- kernel/sched/features.h | 7 +++++++ 1 file changed, 7 insertions(+)