All of lore.kernel.org
 help / color / mirror / Atom feed
From: Len Brown <lenb@kernel.org>
To: Pierre Tardy <tardyp@gmail.com>
Cc: linux-pm@lists.linux-foundation.org, x86@kernel.org,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] intel_idle: disable NHM/WSM HW C-state auto-demotion (v3)
Date: Mon, 28 Feb 2011 11:08:50 -0500 (EST)	[thread overview]
Message-ID: <alpine.LFD.2.02.1102281105460.17782@x980> (raw)
In-Reply-To: <AANLkTinVCvUkmX3pnSy_Ah3fOm6hV-jAPrQXAQ971xnS@mail.gmail.com>

> > Hardware C-state auto-demotion is a mechanism where the HW overrides
> > the OS C-state request, instead demoting to a shallower state,
> > which is less expensive, but saves less power.

> I'm interrested, for pytimechart, to have trace information of what
> actual c-state got reached after each idle request.
> Do you have any info on how to get that?

the actual c-state residency can be seen in the residency 
counters that are exported by turbostat.
However, at the time of the request/return the OS doesn't know
that it's request got demoted demoted (or un-demoted).

No, checking the counters is not something we want to
add to the idle entry/exit path -- they are not optimized for speed.

thanks,
Len Brown, Intel Open Source Technology Center


  parent reply	other threads:[~2011-02-28 16:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-19  2:52 [PATCH] intel_idle: disable HW auto-demotion Len Brown
2011-01-19  5:40 ` [PATCH] intel_idle: disable HW auto-demotion by default (v2) Len Brown
2011-01-19  5:40 ` Len Brown
2011-02-16  6:22   ` [PATCH] intel_idle: disable NHM/WSM HW C-state auto-demotion (v3) Len Brown
2011-02-27 16:17     ` Pierre Tardy
2011-02-28 16:08       ` Len Brown
2011-02-28 16:08       ` Len Brown [this message]
2011-02-27 16:17     ` Pierre Tardy
2011-02-16  6:22   ` Len Brown
2011-01-19 14:41 ` [PATCH] intel_idle: disable HW auto-demotion Matthew Garrett
2011-02-16  6:19   ` Len Brown
2011-02-16  6:19   ` Len Brown
2011-01-19 14:41 ` Matthew Garrett

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=alpine.LFD.2.02.1102281105460.17782@x980 \
    --to=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=tardyp@gmail.com \
    --cc=x86@kernel.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 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.