From: Mike Galbraith <efault@gmx.de>
To: Michael Wang <wangyun@linux.vnet.ibm.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Peter Zijlstra <peterz@infradead.org>,
Alex Shi <alex.shi@intel.com>, Namhyung Kim <namhyung@kernel.org>,
Paul Turner <pjt@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Nikunj A. Dadhania" <nikunj@linux.vnet.ibm.com>,
Ram Pai <linuxram@us.ibm.com>
Subject: Re: [PATCH] sched: wake-affine throttle
Date: Fri, 03 May 2013 07:01:40 +0200 [thread overview]
Message-ID: <1367557300.5907.30.camel@marge.simpson.net> (raw)
In-Reply-To: <51833302.6090208@linux.vnet.ibm.com>
On Fri, 2013-05-03 at 11:46 +0800, Michael Wang wrote:
> On 04/10/2013 11:30 AM, Michael Wang wrote:
>
> Now long time has been passed since the first version, I'd like to
> do some summary about current states:
>
> On a 12 cpu box with tip 3.9.0-rc7, test show that:
>
> 1. remove wake-affine stuff cause regression on hackbench (could be 15%).
> 2. reserve wake-affine stuff cause regression on pgbench (could be 45%).
>
> And since neither remove or reserve is acceptable, this patch introduced a
> knob to throttle wake-affine stuff.
>
> By turning the knob, we could benefit both hackbench and pgbench, or sacrifice
> one to significantly benefit another.
>
> All similar workload which prefer or hate wake-affine behaviour could
> been cared.
>
> If this approach caused any concerns, please let me know ;-)
I wonder if throttling on failure is the way to go. Note the minimal
gain for pgbench with the default 1ms throttle interval. It's not very
effective out of the box for the load type it's targeted to help, and
people generally don't twiddle scheduler knobs. If you throttle on
success, you directly restrict migration frequency without that being
affected by what other tasks are doing. Seems that would be a bit more
effective.
(I still like the wakeup buddy thing, it's more effective because it
adds and uses knowledge, though without the knob, cache domain size.
Peter is right about the interrupt wakeups though, that could very
easily cause regressions, dirt simple throttle is much safer).
-Mike
next prev parent reply other threads:[~2013-05-03 5:01 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-10 3:30 [PATCH] sched: wake-affine throttle Michael Wang
2013-04-10 4:16 ` Alex Shi
2013-04-10 5:11 ` Michael Wang
2013-04-10 5:27 ` Alex Shi
2013-04-10 8:51 ` Peter Zijlstra
2013-04-10 9:22 ` Michael Wang
2013-04-11 6:01 ` Michael Wang
2013-04-11 7:30 ` Mike Galbraith
2013-04-11 8:26 ` Michael Wang
2013-04-11 8:44 ` Mike Galbraith
2013-04-11 9:00 ` Mike Galbraith
2013-04-11 9:02 ` Michael Wang
2013-04-12 3:17 ` Michael Wang
2013-04-22 4:21 ` Michael Wang
2013-04-22 5:27 ` Mike Galbraith
2013-04-22 6:19 ` Michael Wang
2013-04-22 10:23 ` Peter Zijlstra
2013-04-22 10:35 ` Ingo Molnar
2013-04-23 4:05 ` Michael Wang
2013-04-22 17:49 ` Paul Turner
2013-04-23 4:01 ` Michael Wang
2013-04-27 2:46 ` Michael Wang
2013-05-02 5:48 ` Michael Wang
2013-05-02 7:10 ` Mike Galbraith
2013-05-02 7:36 ` Michael Wang
2013-05-03 3:46 ` Michael Wang
2013-05-03 5:01 ` Mike Galbraith [this message]
2013-05-03 5:57 ` Michael Wang
2013-05-03 6:14 ` Mike Galbraith
2013-05-04 2:20 ` Michael Wang
2013-05-07 2:46 ` Michael Wang
2013-05-13 2:27 ` Michael Wang
2013-05-16 7:40 ` Michael Wang
2013-05-16 7:45 ` Michael Wang
2013-05-21 3:20 ` [PATCH v2] " Michael Wang
2013-05-21 6:47 ` Alex Shi
2013-05-21 6:52 ` Michael Wang
2013-05-22 8:49 ` Peter Zijlstra
2013-05-22 9:25 ` Michael Wang
2013-05-22 14:55 ` Mike Galbraith
2013-05-23 2:12 ` Michael Wang
2013-05-28 5:02 ` Michael Wang
2013-05-28 6:29 ` Mike Galbraith
2013-05-28 7:22 ` Michael Wang
2013-05-28 8:49 ` Mike Galbraith
2013-05-28 8:56 ` Michael Wang
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=1367557300.5907.30.camel@marge.simpson.net \
--to=efault@gmx.de \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=alex.shi@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=nikunj@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=wangyun@linux.vnet.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 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.