From: Youquan Song <youquan.song@intel.com>
To: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pm@lists.linux-foundation.org, len.brown@intel.com,
akpm@linux-foundation.org
Cc: arjan@linux.intel.com, len.brown@linux.intel.com,
suresh.b.siddha@intel.com,
Youquan Song <youquan.song@linux.intel.com>,
Youquan Song <youquan.song@intel.com>
Subject: [PATCH 0/3] x86,idle: Enhance cpuidle prediction to handle its failure
Date: Fri, 11 May 2012 11:15:54 -0400 [thread overview]
Message-ID: <1336749357-9133-1-git-send-email-youquan.song@intel.com> (raw)
The prediction for future is difficult and when the cpuidle governor prediction
fails and govenor possibly choose the shallower C-state than it should. How to
quickly notice and find the failure becomes important for power saving.
cpuidle menu governor has a method to predict the repeat pattern if there are 8
C-states residency which are continuous and the same or very close, so it will
predict the next C-states residency will keep same residency time.
We encountered a real case that turbostat utility (tools/power/x86/turbostat)
at kernel 3.3 or early. turbostat utility will read 10 registers one by one at
Sandybridge, so it will generate 10 IPIs to wake up idle CPUs. So cpuidle menu
governor will predict it is repeat mode and there is another IPI wake up idle
CPU soon, so it keeps idle CPU stay at C1 state even though CPU is totally
idle. However, in the turbostat, following 10 registers reading is sleep 5
seconds by default, so the idle CPU will keep at C1 for a long time though it is
idle until break event occurs.
The "old turbostat" is specific case and it is already fix by skip to read CPU
MSRs. But we do not guarantee that other application will not do it like this.
So the proper ways is to enhance the logic of the men governor prediction for
next C-states.
This patchset adds a timer when menu governor choose a non-deepest C-state in
order to wake up quickly from shallow C-state to avoid staying too long at
shallow C-state for prediction failure. If the timer is not triggered and CPU
is waken up from C-state, the timer will be cancelled initiatively to avoid the
adding timer bring affect to system. If the timer is time out, CPU will quickly
be waken up from shallow C-state and re-evaluates deeper C-states possibility.
After plenty of testing and tuning, the patchset get about 1% power efficiency
ehancement in SpecPower2008 on Romley-EP. Especailly, when workload is not so
high < 70%, it can notice 1~3 watts power saving; while workload is high > 80%,
It will cost more power consumption. Another benchmarks non-CPU intensive, like
fio, apache and aio-stress will also get power saving while the performance does
not drop.
While I try to fix the issue, I got a lot of help and suggestion from Arjan,
Thanks a lot Arjan!
Thanks
-Youquan
next reply other threads:[~2012-05-11 15:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-11 15:15 Youquan Song [this message]
2012-05-11 15:15 ` [PATCH 1/3] x86,idle: Quickly notice prediction failure for repeat mode Youquan Song
2012-05-11 15:15 ` [PATCH 2/3] x86,idle: Quickly notice prediction failure in general case Youquan Song
2012-05-11 15:15 ` [PATCH 3/3] x86,idle: Set residency to 0 if target Cstate not really enter 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=1336749357-9133-1-git-send-email-youquan.song@intel.com \
--to=youquan.song@intel.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=len.brown@intel.com \
--cc=len.brown@linux.intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=suresh.b.siddha@intel.com \
--cc=youquan.song@linux.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