[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1626887.BDY94X81Py@vostro.rjw.lan>
Date: Thu, 25 Feb 2016 22:04:29 +0100
From: "Rafael J. Wysocki" <rjw@...ysocki.net>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Steve Muckle <steve.muckle@...aro.org>,
Ingo Molnar <mingo@...hat.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
Vincent Guittot <vincent.guittot@...aro.org>,
Morten Rasmussen <morten.rasmussen@....com>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Juri Lelli <Juri.Lelli@....com>,
Patrick Bellasi <patrick.bellasi@....com>,
Michael Turquette <mturquette@...libre.com>,
Ricky Liang <jcliang@...omium.org>
Subject: Re: [RFCv7 PATCH 03/10] sched: scheduler-driven cpu frequency selection
On Thursday, February 25, 2016 10:21:50 AM Peter Zijlstra wrote:
> On Thu, Feb 25, 2016 at 04:55:57AM +0100, Rafael J. Wysocki wrote:
> > Well, I'm not familiar with static keys and how they work, so you'll need to
> > explain this part to me.
>
> See include/linux/jump_label.h, it has lots of text on them. There is
> also Documentation/static-keys.txt
Thanks for the pointers!
It looks like the author of the $subject patch hasn't looked at the latter
document lately.
In any case, IMO this might be used to hide the cpufreq_update_util() call
sites from the scheduler code in case no one has set anything via
cpufreq_set_update_util_data() for any CPUs.
That essentially is when things like the performance governor are in use,
so may be worth doing, but that's your judgement call mostly. :-)
Thanks,
Rafael
Powered by blists - more mailing lists