public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
To: "Li, Shaohua" <shaohua.li@intel.com>
Cc: "mingo@elte.hu" <mingo@elte.hu>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"svaidy@linux.vnet.ibm.com" <svaidy@linux.vnet.ibm.com>,
	"a.p.zijlstra@chello.nl" <a.p.zijlstra@chello.nl>
Subject: Re: [patch 2/2] x86: put offline CPUs into deepest mwait cstate_subcstate
Date: Tue, 26 May 2009 14:17:46 -0700	[thread overview]
Message-ID: <1243372667.4534.21.camel@localhost.localdomain> (raw)
In-Reply-To: <20090525005646.GA9093@sli10-desk.sh.intel.com>

On Sun, 2009-05-24 at 17:56 -0700, Li, Shaohua wrote:
> On Sat, May 23, 2009 at 07:19:42AM +0800, Pallipadi, Venkatesh wrote:
> > Offline CPUs can save power by going into deepest cstate, subcstate
> > instead of hlt loop.
> > 
> > Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
> > ---
> >  arch/x86/kernel/acpi/cstate.c |   51 +++++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 51 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
> > index bbbe4bb..5b0988a 100644
> > --- a/arch/x86/kernel/acpi/cstate.c
> > +++ b/arch/x86/kernel/acpi/cstate.c
> > @@ -150,6 +150,54 @@ void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx *cx)
> >  }
> >  EXPORT_SYMBOL_GPL(acpi_processor_ffh_cstate_enter);
> >  
> > +static unsigned long mwait_play_dead_eax;
> > +
> > +static void mwait_play_dead(void)
> > +{
> > +	if (boot_cpu_data.x86 >= 4)
> > +		wbinvd();
> > +
> > +	while (1) {
> > +		__monitor((void *)&current_thread_info()->flags, 0, 0);
> > +		smp_mb();
> > +		__mwait(mwait_play_dead_eax, 0);
> > +	}
> > +}
> CPU is dead, can current_thread_info() still be used? Maybe just monitor a never changed
> address.
> 

We still execute in this while loop even for an offline CPU, in case CPU
just wakes up for whatever reason (HT sibling woke up etc). So, we
should have stack and current_thread_info() even when offline, and we
can use it here. I had a never changing variable in my earlier version
of this patch. But removed it as I don't see why we should have couple
of cache lines of data when we can avoid it.

> Looks the patch will always take the highest native C-state, is this safe, considering
> BIOS usually limit C-state?
> 

It may not be safe in terms of wakeup latency etc. So, we use BIOS CST
for normal C-states. When offline, we don't really care about latency
part. If CPU supports a C-state, we should be able to enter it and we
can save most power with deepest C-state. If there are functionality
issues with C-state, I am sure CPU feature (hw or microcode) will have
it disabled, instead of depending on BIOSes to disable it.

Thanks,
Venki


  reply	other threads:[~2009-05-26 21:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-22 23:19 [patch 0/2] x86: Make offline cpus to go to deepest idle state using mwait venkatesh.pallipadi
2009-05-22 23:19 ` [patch 1/2] x86: Add pm_play_dead funcptr to power-efficiently offline CPUs venkatesh.pallipadi
2009-05-23 10:44   ` Peter Zijlstra
2009-05-23 15:07     ` Pallipadi, Venkatesh
2009-06-22 17:25     ` Pallipadi, Venkatesh
2009-05-22 23:19 ` [patch 2/2] x86: put offline CPUs into deepest mwait cstate_subcstate venkatesh.pallipadi
2009-05-25  0:56   ` Shaohua Li
2009-05-26 21:17     ` Pallipadi, Venkatesh [this message]
2010-09-17 23:46   ` [tip:x86/idle] x86, hotplug: Use mwait to offline a processor, fix the legacy case tip-bot for H. Peter Anvin
2010-09-18  0:13     ` [tip:x86/idle] x86, hotplug: Move WBINVD back outside the play_dead loop tip-bot for H. Peter Anvin
2010-09-18  0:48       ` Venkatesh Pallipadi
2010-09-20 18:20         ` H. Peter Anvin
2010-09-20 20:11           ` H. Peter Anvin
2010-09-20 22:34             ` Venkatesh Pallipadi

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=1243372667.4534.21.camel@localhost.localdomain \
    --to=venkatesh.pallipadi@intel.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=hpa@zytor.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=shaohua.li@intel.com \
    --cc=svaidy@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    /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