From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>, Mike Galbraith <efault@gmx.de>,
linux-kernel@vger.kernel.org,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
Subject: Re: [PATCH 0/2] RFC: readd fair sleepers for server systems
Date: Tue, 22 May 2012 11:01:08 +0200 [thread overview]
Message-ID: <1337677268.9698.6.camel@twins> (raw)
In-Reply-To: <1337615137-55111-1-git-send-email-schwidefsky@de.ibm.com>
On Mon, 2012-05-21 at 17:45 +0200, Martin Schwidefsky wrote:
> our performance team found a performance degradation with a recent
> distribution update in regard to fair sleepers (or the lack of fair
> sleepers). On s390 we used to run with fair sleepers disabled.
This change was made a very long time ago.. tell your people to mind
what upstream does if they want us to mind them.
Also, reports like this make me want to make /debug/sched_features a
patch in tip/out-of-tree so that its never available outside
development.
> We see the performance degradation with our network benchmark and fair
> sleepers enabled, the largest hit is on virtual connections:
>
> VM guest Hipersockets
> Throughput degrades up to 18%
> CPU load/cost increase up to 17%
> VM stream
> Throughput degrades up to 15%
> CPU load/cost increase up to 22%
> LPAR Hipersockets
> Throughput degrades up to 27%
> CPU load/cost increase up to 20%
Why is this, is this some weird interaction with your hypervisor?
> In short, we want the fair sleepers tunable back. I understand that on
> x86 we want to avoid the cost of a branch on the hot path in place_entity,
> therefore add a compile time config option for the fair sleeper control.
I'm very much not liking this... this makes s390 schedule completely
different from all the other architectures.
next prev parent reply other threads:[~2012-05-22 9:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-21 15:45 [PATCH 0/2] RFC: readd fair sleepers for server systems Martin Schwidefsky
2012-05-21 15:45 ` [PATCH 1/2] sched: readd FAIR_SLEEPERS feature Martin Schwidefsky
2012-05-22 7:11 ` Christian Ehrhardt
2012-05-22 9:06 ` Mike Galbraith
2012-05-21 15:45 ` [PATCH 2/2] sched: enable FAIR_SLEEPERS for s390 Martin Schwidefsky
2012-05-21 18:17 ` [PATCH 0/2] RFC: readd fair sleepers for server systems Mike Galbraith
2012-05-22 7:11 ` Christian Ehrhardt
2012-05-22 8:53 ` Mike Galbraith
2012-05-22 9:01 ` Peter Zijlstra [this message]
2012-05-23 11:32 ` Christian Ehrhardt
2012-05-23 11:49 ` Peter Zijlstra
2012-05-23 15:28 ` Christian Ehrhardt
2012-05-23 15:43 ` Peter Zijlstra
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=1337677268.9698.6.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=efault@gmx.de \
--cc=ehrhardt@linux.vnet.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=schwidefsky@de.ibm.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