All of lore.kernel.org
 help / color / mirror / Atom feed
From: Youquan Song <youquan.song@linux.intel.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Youquan Song <youquan.song@intel.com>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	arjan@linux.intel.com, lenb@kernel.org,
	Rik van Riel <riel@redhat.com>,
	Youquan Song <youquan.song@linux.intel.com>
Subject: Re: [PATCH V2 0/3] x86,idle: Enhance cpuidle prediction to handle its failure
Date: Mon, 17 Sep 2012 23:30:20 -0400	[thread overview]
Message-ID: <20120918033020.GA20862@linux-youquan.bj.intel.com> (raw)
In-Reply-To: <50573934.4030102@linaro.org>

> > One case is 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.
> > In a idle Sandybridge system, run "./turbostat -v", we will notice that deep 
> > C-state dangles between "70% ~ 99%". After patched the kernel, we will notice
> > deep C-state stays at >99.98%.
> 
> Is there an impact on performances ?

In this case, turbostat is utility to measure cpu idle status and itself
also is a workload to system. Its purpose is that show cpu C-state
information every 5 seconds. After patched the kernel, it also does
the same thing as usual. So I think the performance has no/little impact.

I do not find performance impact in my tests. If you performance impact cases or
suggestions, I will be very glad to try. 

Thanks
-Youquan

  reply	other threads:[~2012-09-17 15:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-18  1:53 [PATCH V2 0/3] x86,idle: Enhance cpuidle prediction to handle its failure Youquan Song
2012-09-17 14:52 ` Daniel Lezcano
2012-09-17 14:52   ` Daniel Lezcano
2012-09-18  3:30   ` Youquan Song [this message]
2012-09-17 20:32     ` Daniel Lezcano
2012-09-18  1:53 ` [PATCH V2 1/3] x86,idle: Quickly notice prediction failure for repeat mode Youquan Song
2012-09-17 13:59   ` Rik van Riel
2012-09-18  2:15     ` Youquan Song
2012-09-18  1:53   ` [PATCH V2 2/3] x86,idle: Quickly notice prediction failure in general case Youquan Song
2012-09-18  1:53     ` [PATCH V2 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=20120918033020.GA20862@linux-youquan.bj.intel.com \
    --to=youquan.song@linux.intel.com \
    --cc=arjan@linux.intel.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.