public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Venki Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: Add clflush before monitor for Intel 7400 series
Date: Tue, 07 Oct 2008 16:02:47 -0700	[thread overview]
Message-ID: <48EBEA97.9020404@zytor.com> (raw)
In-Reply-To: <20081007214920.GA17439@linux-os.sc.intel.com>

Venki Pallipadi wrote:
> On Tue, Oct 07, 2008 at 02:09:12PM -0700, H. Peter Anvin wrote:
>> Venki Pallipadi wrote:
>>> For Intel 7400 series CPUs, the recommendation is to use a clflush on the
>>> monitored address just before monitor and mwait pair [1]. This clflush makes
>>> sure that there are no false wakeups from mwait when the monitored address
>>> was recently written to.
>>>
>>> [1] "MONITOR/MWAIT Recommendations for Intel Xeon Processor 7400 series"
>>> section in specification update document of 7400 series
>>> http://download.intel.com/design/xeon/specupdt/32033601.pdf
>>>
>>> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
>> This seems very expensive.  It really makes me wonder if it wouldn't
>> just be better to either declare monitor/mwait non-functional on this
>> chip, or make sure that mwaits can handle false wakeups.
> 
> mwait can handle false wakeups. Today we wake backup all the way and find
> out there is nothing to do and go back to idle. And second time around this
> false wakeup does not happen as we do not write to monitored address in the
> interim. The problem we saw was the places where we try to look at how
> long each idle period was and take power management decision for the next idle.
> Such algorithms get confused with false wakeups.

Do you have any concept of how often this happens?  Every time?  Small 
fraction?

> Yes. Other alternative is to disable mwaits altogether on these CPUs. I can
> send a patch to do that. But, the patch will be somewhat more complicated
> as kernel advertises the MWAIT capability to firmware with a ACPI _PDC method
> and BIOS has to then give IO port based C2 for us to use in such case.
> Avoiding mwait just for C1 is easy though.

It would be my weak preference, although I'm willing to be convinced 
that mwait is worth the power savings even with the workaround.

	-hpa


  reply	other threads:[~2008-10-07 23:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-07 21:00 [PATCH] x86: Add clflush before monitor for Intel 7400 series Venki Pallipadi
2008-10-07 21:09 ` H. Peter Anvin
2008-10-07 21:49   ` Venki Pallipadi
2008-10-07 23:02     ` H. Peter Anvin [this message]
2008-10-17 20:05       ` Pallipadi, Venkatesh
2008-10-17 20:13         ` H. Peter Anvin
2008-10-17 20:51           ` Pallipadi, Venkatesh
2008-10-17 22:49             ` H. Peter Anvin
2008-10-18  7:15               ` Andi Kleen

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=48EBEA97.9020404@zytor.com \
    --to=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=venkatesh.pallipadi@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