From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Turquette Subject: Re: [RFCv5 PATCH 39/46] sched/cpufreq_sched: use static key for cpu frequency selection Date: Wed, 08 Jul 2015 08:19:56 -0700 Message-ID: <20150708151956.9112.52403@quantum> References: <1436293469-25707-1-git-send-email-morten.rasmussen@arm.com> <1436293469-25707-40-git-send-email-morten.rasmussen@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Return-path: Received: from mail-pa0-f42.google.com ([209.85.220.42]:33505 "EHLO mail-pa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933622AbbGHPUP convert rfc822-to-8bit (ORCPT ); Wed, 8 Jul 2015 11:20:15 -0400 Received: by pacws9 with SMTP id ws9so134822396pac.0 for ; Wed, 08 Jul 2015 08:20:15 -0700 (PDT) In-Reply-To: <1436293469-25707-40-git-send-email-morten.rasmussen@arm.com> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Morten Rasmussen , peterz@infradead.org, mingo@redhat.com Cc: vincent.guittot@linaro.org, daniel.lezcano@linaro.org, Dietmar Eggemann , yuyang.du@intel.com, rjw@rjwysocki.net, Juri Lelli , sgurrappadi@nvidia.com, pang.xunlei@zte.com.cn, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Juri Lelli Quoting Morten Rasmussen (2015-07-07 11:24:22) > From: Juri Lelli > > Introduce a static key to only affect scheduler hot paths when sched > governor is enabled. > > cc: Ingo Molnar > cc: Peter Zijlstra > > Signed-off-by: Juri Lelli > --- > kernel/sched/cpufreq_sched.c | 14 ++++++++++++++ > kernel/sched/fair.c | 1 + > kernel/sched/sched.h | 6 ++++++ > 3 files changed, 21 insertions(+) > > diff --git a/kernel/sched/cpufreq_sched.c b/kernel/sched/cpufreq_sched.c > index 5020f24..2968f3a 100644 > --- a/kernel/sched/cpufreq_sched.c > +++ b/kernel/sched/cpufreq_sched.c > @@ -203,6 +203,18 @@ void cpufreq_sched_set_cap(int cpu, unsigned long capacity) > return; > } > > +static inline void set_sched_energy_freq(void) > +{ > + if (!sched_energy_freq()) > + static_key_slow_inc(&__sched_energy_freq); > +} > + > +static inline void clear_sched_energy_freq(void) > +{ > + if (sched_energy_freq()) > + static_key_slow_dec(&__sched_energy_freq); > +} > + > static int cpufreq_sched_start(struct cpufreq_policy *policy) > { > struct gov_data *gd; > @@ -243,6 +255,7 @@ static int cpufreq_sched_start(struct cpufreq_policy *policy) > > policy->governor_data = gd; > gd->policy = policy; > + set_sched_energy_freq(); > return 0; > > err: > @@ -254,6 +267,7 @@ static int cpufreq_sched_stop(struct cpufreq_policy *policy) > { > struct gov_data *gd = policy->governor_data; > > + clear_sched_energy_freq(); These controls are exposed to userspace via cpufreq sysfs knobs. Should we use a struct static_key_deferred and static_key_slow_dec_deferred() instead? This helps avoid a possible attack vector for slowing down the system. I don't really know what a sane default rate limit would be in that case though. Otherwise feel free to add: Reviewed-by: Michael Turquette Regards, Mike > if (cpufreq_driver_might_sleep()) { > kthread_stop(gd->task); > } > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index f7cb6c9..d395bc9 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -4282,6 +4282,7 @@ static inline void hrtick_update(struct rq *rq) > #endif > > static bool cpu_overutilized(int cpu); > +struct static_key __sched_energy_freq __read_mostly = STATIC_KEY_INIT_FALSE; > > /* > * The enqueue_task method is called before nr_running is > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h > index 30aa0c4..b5e27d9 100644 > --- a/kernel/sched/sched.h > +++ b/kernel/sched/sched.h > @@ -1476,6 +1476,12 @@ unsigned long arch_scale_cpu_capacity(struct sched_domain *sd, int cpu) > } > #endif > > +extern struct static_key __sched_energy_freq; > +static inline bool sched_energy_freq(void) > +{ > + return static_key_false(&__sched_energy_freq); > +} > + > #ifdef CONFIG_CPU_FREQ_GOV_SCHED > void cpufreq_sched_set_cap(int cpu, unsigned long util); > #else > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/