Hi,
On 16/04/15 19:41, Michael Turquette wrote:
Quoting Juri Lelli (2015-04-16 09:53:28)
Hi Mike,
On 16/04/15 06:29, Michael Turquette wrote:
This patch introduces the SCHED_ENERGY_FREQ sched feature, which is implemented using jump labels when SCHED_DEBUG is defined. It is statically set to false when SCHED_DEBUG is not defined and thus disabled by default.
Signed-off-by: Michael Turquette mturquette@linaro.org
kernel/sched/fair.c | 5 +++++ kernel/sched/features.h | 6 ++++++ 2 files changed, 11 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 46855d0..75aec8d 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4207,6 +4207,11 @@ static inline void hrtick_update(struct rq *rq) } #endif +static inline bool sched_energy_freq(void) +{
return sched_feat(SCHED_ENERGY_FREQ);+}
/*
- The enqueue_task method is called before nr_running is
- increased. Here we update the fair scheduling stats and
diff --git a/kernel/sched/features.h b/kernel/sched/features.h index 91e33cd..77381cf 100644 --- a/kernel/sched/features.h +++ b/kernel/sched/features.h @@ -96,3 +96,9 @@ SCHED_FEAT(NUMA_FAVOUR_HIGHER, true) */ SCHED_FEAT(NUMA_RESIST_LOWER, false) #endif
+/*
- Scheduler-driven CPU frequency selection aimed to save energy based on
- load tracking
- */
+SCHED_FEAT(SCHED_ENERGY_FREQ, false)
Do we really need this? I understand that you don't want to add overhead in enqueue/dequeue/etc paths, but to me it looks a bit redundant as to enable the governor we have to both set it in scaling_governor and enable this sched feature.
I do not think it is redundant. If we remove this but the governor is not active then there is still overhead. cap_gov_update_cpu will call cpufreq_cpu_get(int cpu), fetch the policy pointer and only after that will we realize that there is no policy.gov_data, at which point we bail.
I'd prefer to avoid running through this code every time we enter {en,de}queue_task_fair and task_tick_fair.
Completely agree. That's exactly what I meant with "I understand that you don't want...", thanks for clarifying :).
An alternative might be to keep per-cpu pointers to gov_data. Then we only need to check for !per_cpu(cap_gov_data, cpu) and bail quickly.
Yeah, something like this might work better IMHO, so that we have a single switch for the whole thing.
Thanks,
- Juri
Regards, Mike
Thanks,
- Juri