From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
H Peter Anvin <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
tglx@linutronix.de, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: Add clflush before monitor for Intel 7400 series - v2
Date: Mon, 09 Feb 2009 13:37:17 -0800 [thread overview]
Message-ID: <1234215437.4286.396.camel@localhost.localdomain> (raw)
In-Reply-To: <200902091653.26570.nickpiggin@yahoo.com.au>
On Sun, 2009-02-08 at 21:53 -0800, Nick Piggin wrote:
> On Sunday 08 February 2009 03:47:07 Pallipadi, Venkatesh wrote:
> > On Sat, Feb 07, 2009 at 06:02:45AM -0800, Alan Cox wrote:
> > > On Fri, 6 Feb 2009 16:47:29 -0800
> > >
> > > "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> 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.
> > >
> > > Given our mwait usages will very quickly go back to sleep in such a case
> > > and it would almost certainly be one sleep only is this really worth the
> > > effort ?
> >
> > Yes. If we only consider the CPU idle behavior, we really do not need the
> > patch as we will go back to idle. But, there are other factors:
> > - drivers/idle/i7300_idle.c which tries to save memory power based on CPU
> > idle time. It gets confused with these short idles.
> > - cpuidle menu governor These platforms may also support more than one
> > C-state. C1 and CC3. So, we will go through the C-state policy in menu
> > governor, which again looks at idle time and may end up taking wrong
> > decisions due to these short idles.
> >
> > We can make the above code to be more clever, to ignore short idles. But,
> > this patch seems to be the easier and clean way as the errata is only in a
> > particular CPU model.
>
> Have you benchmarked it? With something like tbench which IIRC should
> generate a good number of idle/busy transitions?
>
We haven't run tbench specifically. But, we noticed this issue running
specpower workload on this platform. Especially the 10-20% point of
specpower, which also has notable idle/busy transitions, this patch
helps.
Thanks,
Venki
next prev parent reply other threads:[~2009-02-09 21:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-07 0:47 [PATCH] x86: Add clflush before monitor for Intel 7400 series - v2 Pallipadi, Venkatesh
2009-02-07 14:02 ` Alan Cox
2009-02-07 16:47 ` Pallipadi, Venkatesh
2009-02-09 5:53 ` Nick Piggin
2009-02-09 21:37 ` Pallipadi, Venkatesh [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-02-07 0:52 Pallipadi, Venkatesh
2009-02-09 10:15 ` Ingo Molnar
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=1234215437.4286.396.camel@localhost.localdomain \
--to=venkatesh.pallipadi@intel.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--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 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.