From: Mel Gorman <mgorman@suse.de>
To: Len Brown <len.brown@intel.com>
Cc: athorlton@sgi.com, riel@redhat.com, chegu_vinod@hp.com,
Greg KH <gregkh@linuxfoundation.org>,
"H. Peter Anvin" <hpa@linux.intel.com>,
LKML <linux-kernel@vger.kernel.org>,
stable@vger.kernel.org
Subject: Re: Idle power fix regresses ebizzy performance (was 3.12-stable backport of NUMA balancing patches)
Date: Mon, 13 Jan 2014 19:24:06 +0000 [thread overview]
Message-ID: <20140113192406.GL27046@suse.de> (raw)
In-Reply-To: <20140108134858.GF27046@suse.de>
On Wed, Jan 08, 2014 at 01:48:58PM +0000, Mel Gorman wrote:
> Adding LKML to the list as this -stable snifftest has identified an
> upstream regression.
>
This is a false alarm.
The test machine in question was originally installed based on a beta
version of openSUSE 13.1. It included a package by default that set default
malloc parameters that I was not aware. Normally the package is there to
catch bugs during beta testing and removed before a GA release but it's
left in place if a user does a distribution update.
With the debugging RPM installed, the free paths contended on a global
mutex in glibc. Ebizzy had been classified as a CPU intensive and memory
free intensive benchmark (not that common) but turbostat showed that the
CPUs were over 95% of the time in C6 and mpstat verified that the CPUs
were mostly idle. It did not take long to see that everything was blocked
waiting on a futex and to identify where it was in glibc. It's only a
factor when malloc debugging is enabled so normally people would not see it.
The "regression" is because CPUs are reaching C6 as they should and there
is a delay when exiting it. This is behaving as designed and fixing this
would involve doing something stupid. Once the problem RPM was removed
ebizzy performed as expected. 3.13-rc7, the revert and forcing max_cstate=1
all have similar performance.
Sorry about the noise.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2014-01-13 19:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1389103248-17617-1-git-send-email-mgorman@suse.de>
[not found] ` <20140107141715.GA32491@kroah.com>
[not found] ` <20140107185440.GA7844@kroah.com>
[not found] ` <20140107203012.GA27046@suse.de>
[not found] ` <20140108104340.GC27046@suse.de>
2014-01-08 13:48 ` Idle power fix regresses ebizzy performance (was 3.12-stable backport of NUMA balancing patches) Mel Gorman
2014-01-09 4:17 ` Greg KH
2014-01-09 20:07 ` Len Brown
2014-01-10 10:14 ` Mel Gorman
[not found] ` <CAJvTdK=vJxYgtLOYZZPrwGNgYQrFVeCq18RwzEfh5n_tZyeP9g@mail.gmail.com>
2014-01-10 10:26 ` Mel Gorman
2014-01-10 14:38 ` Mel Gorman
2014-01-13 19:24 ` Mel Gorman [this message]
2014-01-13 21:12 ` Greg KH
2014-01-14 7:31 ` Len Brown
2014-01-14 8:01 ` Mike Galbraith
2014-01-14 8:24 ` Mike Galbraith
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=20140113192406.GL27046@suse.de \
--to=mgorman@suse.de \
--cc=athorlton@sgi.com \
--cc=chegu_vinod@hp.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@linux.intel.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@redhat.com \
--cc=stable@vger.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.