From: Thomas Renninger <trenn@suse.de>
To: Jacob Shin <jacob.shin@amd.com>
Cc: Borislav Petkov <bp@alien8.de>, "Rafael J. Wysocki" <rjw@sisk.pl>,
cpufreq@vger.kernel.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org,
Viresh Kumar <viresh.kumar@linaro.org>
Subject: Re: [PATCH V3 2/2] cpufreq: AMD "frequency sensitivity feedback" powersave bias for ondemand governor
Date: Tue, 02 Apr 2013 22:51:51 +0200 [thread overview]
Message-ID: <2932884.BNCEuERbdR@skinner.arch.suse.de> (raw)
In-Reply-To: <20130402200337.GA17919@jshin-Toonie>
On Tuesday, April 02, 2013 03:03:37 PM Jacob Shin wrote:
> On Tue, Apr 02, 2013 at 09:23:52PM +0200, Borislav Petkov wrote:
> > On Tue, Apr 02, 2013 at 01:11:44PM -0500, Jacob Shin wrote:
> > > Future AMD processors, starting with Family 16h, can provide software
> > > with feedback on how the workload may respond to frequency change --
> > > memory-bound workloads will not benefit from higher frequency, where
> > > as compute-bound workloads will. This patch enables this "frequency
> > > sensitivity feedback" to aid the ondemand governor to make better
> > > frequency change decisions by hooking into the powersave bias.
I had a quick look at the specification of these registers.
So this seem to be designed and stay very cpufreq specific and other kernel
parts probably won't make use of it.
...
> > > +
> > > + /* this workload is not CPU bound, so choose a lower freq */
> > > + if (sensitivity < od_tuners->powersave_bias) {
> >
> > Ok, I still didn't get an answer to that: don't we want to use this
> > feature by default, even without looking at ->powersave_bias? I mean,
> > with feedback from the hardware, we kinda know better than the user, no?
>
> Well, so this powersave_bias also works as a tunable knob.
>
> From ondemand side, if /sys/../ondemand/powersave_bias is 0, then we
> (AMD sensitivity) don't get called and you get the default ondemand
> behavior.
>
> Like existing powersave_bias, users can tune the value to whatever
> they want, to get a specturum of less to more aggressive power savings
> vs performance.
I understand powersave_bias code to only be able to do a more
aggressive power saving way:
If you pass 900, a frequency of 90% (for example 900MHz instead of 1000MHz)
of the one ondemand typically would choose is taken.
powersave_bias values above 1000 (take higher frequencies than the ondemand
would take) are not allowed.
powersave_bias is undocumented in Documentation/cpu-freq/...
I guess its use-case is for people who want to get some percent more
power savings out of their laptop and do not care of the one or other
percent performance.
In fact I would like to get rid of this extra code and I expect nobody would
miss it.
I might miss a configuration tool where someone went through the code,
documented things and allows users to set powersave_bias values through
some /etc/* config files.
If so, please point me to it.
What your patch misses are some hints how and when to use this at all.
What value should a user write to powersave_bias tunable to activate your
stuff?
I guess it's also for laptop users to get some percent more battery out of
their platform and this with an even higher performance rate?
Server guys do not care for some percent of power, but they do care for
some percent of performance.
> I thought tunable would be more flexible .. out in the field or what
> not .. no?
Yep, if you want anyone to make use of this, it should better get embedded
in more general, at least general ondemand code.
Thomas
next prev parent reply other threads:[~2013-04-02 20:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-02 18:11 [PATCH V3 0/2] cpufreq: ondemand: add AMD specific powersave bias Jacob Shin
2013-04-02 18:11 ` [PATCH V3 1/2] cpufreq: ondemand: allow custom powersave_bias_target handler to be registered Jacob Shin
2013-04-02 19:24 ` Borislav Petkov
2013-04-03 5:12 ` Viresh Kumar
2013-04-02 18:11 ` [PATCH V3 2/2] cpufreq: AMD "frequency sensitivity feedback" powersave bias for ondemand governor Jacob Shin
2013-04-02 19:23 ` Borislav Petkov
2013-04-02 20:03 ` Jacob Shin
2013-04-02 20:40 ` Borislav Petkov
2013-04-02 20:51 ` Thomas Renninger [this message]
2013-04-02 21:01 ` Borislav Petkov
2013-04-03 16:53 ` Jacob Shin
2013-04-03 17:04 ` Borislav Petkov
2013-04-03 17:17 ` Jacob Shin
2013-04-03 17:30 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2932884.BNCEuERbdR@skinner.arch.suse.de \
--to=trenn@suse.de \
--cc=bp@alien8.de \
--cc=cpufreq@vger.kernel.org \
--cc=jacob.shin@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox