From: Youquan Song <youquan.song@linux.intel.com>
To: Matthew Garrett <mjg@redhat.com>
Cc: Youquan Song <youquan.song@intel.com>,
davej@redhat.com, cpufreq@vger.kernel.org, venki@google.com,
arjan@linux.intel.com, lenb@kernel.org,
suresh.b.siddha@intel.com, kent.liu@intel.com,
chaohong.guo@intel.com, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org,
Youquan Song <youquan.song@linux.intel.com>
Subject: Re: [PATCH 0/6] cpufreq: Add sampling window to enhance ondemand governor power efficiency
Date: Thu, 23 Dec 2010 23:28:09 -0500 [thread overview]
Message-ID: <20101224042809.GA15773@linux-youquan.bj.intel.com> (raw)
In-Reply-To: <20101223144220.GB1402@srcf.ucam.org>
On Thu, Dec 23, 2010 at 02:42:20PM +0000, Matthew Garrett wrote:
> We've generally been assuming (rightly or wrongly) that getting into
> deep C states is preferable to being active (even at a lower frequency),
> and so the current behaviour of tending to rapidly switch to the maximum
> P state isn't inherently a problem. What kind of power savings are you
> benchmarking with this, and do you still see a saving if you just
> disable turbo mode?
Thanks a lot! Matthew.
Running the well-known power and performance benchmark,
performance/watts improve around 10%, the performance without drop.
Other benchmarks: kernel buiding and compress-7zip, power saving 2%~5%,
the performance also without drop.
Exception was: apache benchmark, it will let the performance drop
without much power save. These say that it depends on workload itself
to save how much power.
I also consider that this patchset is effective to save power when workload
intermediately be idle, during the idle period, the workload is purely
idle not waiting for something happened. Because the low frequency will
try to fill up these idle periods while Turbo frequency execute quickly
consume much more power than low frequency, then be purely idle. In
this situation, use low frequency will save power.
But if the workload is not purely idle,we low the frequency to execute,
it will sacrifice the performance while it also do not save power.
In this situation, I will try to decrease to sampling window to samping
rate (10ms), it will roll back and keep the same behaviour as original
ondemand does. I need more investigation about how to identify out
these purely idle or not. Do you have idea about it?
I run benchmark at two situations: one is userspace governor, set all cpu frequency
P1 and other is set to powersave, there is no much different between these two
result. So it say that there is not much value to tuning between Pn to
P1(no-turbo mode).
While I compare result of userspace with all P1 frequency and
Performance(Turbo Mode), there are much room to tuning. It is the
original drive for me to do this patchset.
Thanks
-Youquan
next prev parent reply other threads:[~2010-12-23 15:19 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-23 6:23 [PATCH 0/6] cpufreq: Add sampling window to enhance ondemand governor power efficiency Youquan Song
2010-12-23 6:23 ` [PATCH 1/6] cpufreq: Add sampling window for ondemand governor Youquan Song
2010-12-23 6:23 ` [PATCH 2/6] cpufreq: Add sampling_window tunable Youquan Song
2010-12-23 6:23 ` [PATCH 3/6] cpufreq: Add roll back non-sampling_window Youquan Song
2010-12-23 6:23 ` [PATCH 4/6] cpufreq: Add dynamic sampling window tunable Youquan Song
2010-12-23 6:23 ` [PATCH 5/6] cpufreq: Add down_differential tunable Youquan Song
2010-12-23 6:23 ` [PATCH 6/6] cpufreq: Evaluate P1 before enter turbo mode Youquan Song
2010-12-23 10:57 ` Dominik Brodowski
2010-12-23 14:38 ` Matthew Garrett
2010-12-23 18:13 ` Venkatesh Pallipadi
2010-12-23 20:48 ` Dominik Brodowski
2010-12-23 11:00 ` [PATCH 0/6] cpufreq: Add sampling window to enhance ondemand governor power efficiency Dominik Brodowski
2010-12-23 17:34 ` Dave Jones
[not found] ` <20101223173402.GA3821@redhat.com>
2010-12-23 20:51 ` Dominik Brodowski
[not found] ` <20101223205148.GB6441@comet.dominikbrodowski.net>
2010-12-25 4:24 ` James Cloos
2010-12-24 3:06 ` Youquan Song
2010-12-23 14:42 ` Matthew Garrett
2010-12-24 4:28 ` Youquan Song [this message]
[not found] ` <BBBDBC5FD59D92459FAEF7D8EA3361C402A1A424@DUL1WNEXMB05.vcorp.ad.vrsn.com>
2010-12-23 23:26 ` Youquan Song
-- strict thread matches above, loose matches on Subject: below --
2010-12-23 6:17 Youquan Song
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=20101224042809.GA15773@linux-youquan.bj.intel.com \
--to=youquan.song@linux.intel.com \
--cc=arjan@linux.intel.com \
--cc=chaohong.guo@intel.com \
--cc=cpufreq@vger.kernel.org \
--cc=davej@redhat.com \
--cc=kent.liu@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg@redhat.com \
--cc=suresh.b.siddha@intel.com \
--cc=venki@google.com \
--cc=youquan.song@intel.com \
/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