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 <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: [RFC PATCH] sched: smart wake-affine
Date: Mon, 03 Jun 2013 05:53:17 +0200 [thread overview]
Message-ID: <1370231597.5988.79.camel@marge.simpson.net> (raw)
In-Reply-To: <51AC0CD4.9070302@linux.vnet.ibm.com>
On Mon, 2013-06-03 at 11:26 +0800, Michael Wang wrote:
> On 06/03/2013 11:09 AM, Mike Galbraith wrote:
> > On Mon, 2013-06-03 at 10:28 +0800, Michael Wang wrote:
> >> On 05/28/2013 01:05 PM, Michael Wang wrote:
> >>> wake-affine stuff is always trying to pull wakee close to waker, by theory,
> >>> this will bring benefit if waker's cpu cached hot data for wakee, or the
> >>> extreme ping-pong case.
> >>>
> >>> And testing show it could benefit hackbench 15% at most.
> >>>
> >>> However, the whole stuff is somewhat blindly and time-consuming, some
> >>> workload therefore suffer.
> >>>
> >>> And testing show it could damage pgbench 50% at most.
> >>>
> >>> Thus, wake-affine stuff should be smarter, and realise when to stop
> >>> it's thankless effort.
> >>
> >> Is there any comments?
> >
> > (I haven't had time to test-drive yet, -rt munches time like popcorn)
>
> I see ;-)
>
> During my testing, this one works well on the box, solved the issues of
> pgbench and won't harm hackbench any, I think we have caught some good
> point here :)
Some wider spectrum testing needs doing though. Hackbench is a good
sign, but localhost and db type stuff that really suffer from misses
would be good to test. Java crud tends to be sensitive too. I used to
watch vmark (crap) as an indicator, if you see unhappiness there, you'll
very likely see it in other loads as well, it is very fond of cache
affine wakeups, but loathes preemption (super heavy loads usually do).
-Mike
next prev parent reply other threads:[~2013-06-03 3:53 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-28 5:05 Michael Wang
2013-06-03 2:28 ` Michael Wang
2013-06-03 3:09 ` Mike Galbraith
2013-06-03 3:26 ` Michael Wang
2013-06-03 3:53 ` Mike Galbraith [this message]
2013-06-03 4:52 ` Michael Wang
2013-06-03 5:22 ` Mike Galbraith
2013-06-03 5:50 ` Michael Wang
2013-06-03 6:05 ` Mike Galbraith
2013-06-03 6:31 ` Michael Wang
2013-06-13 3:09 ` Michael Wang
2013-07-02 4:43 ` [PATCH] " Michael Wang
2013-07-02 5:38 ` Mike Galbraith
2013-07-02 5:50 ` Michael Wang
2013-07-02 5:54 ` Mike Galbraith
2013-07-02 6:17 ` Michael Wang
2013-07-02 6:29 ` Mike Galbraith
2013-07-02 6:45 ` Michael Wang
2013-07-02 8:52 ` Peter Zijlstra
2013-07-02 9:35 ` Michael Wang
2013-07-02 9:44 ` Michael Wang
2013-07-04 9:13 ` Peter Zijlstra
2013-07-04 9:38 ` Michael Wang
2013-07-04 10:33 ` Mike Galbraith
2013-07-05 2:47 ` Michael Wang
2013-07-05 4:08 ` Mike Galbraith
2013-07-05 4:33 ` Michael Wang
2013-07-05 5:41 ` Mike Galbraith
2013-07-05 6:16 ` Michael Wang
2013-07-07 6:43 ` Mike Galbraith
2013-07-08 2:49 ` Michael Wang
2013-07-08 3:12 ` Mike Galbraith
2013-07-08 8:21 ` Peter Zijlstra
2013-07-08 8:49 ` Mike Galbraith
2013-07-08 9:08 ` Michael Wang
2013-07-08 8:58 ` Michael Wang
2013-07-08 18:59 ` Davidlohr Bueso
2013-07-09 2:30 ` Michael Wang
2013-07-09 2:36 ` Davidlohr Bueso
2013-07-09 2:52 ` Michael Wang
2013-07-15 5:13 ` Michael Wang
2013-07-15 5:57 ` Davidlohr Bueso
2013-07-15 6:01 ` Michael Wang
2013-07-18 2:15 ` Michael Wang
2013-07-03 6:10 ` [PATCH v2] " Michael Wang
2013-07-03 8:50 ` Peter Zijlstra
2013-07-03 9:11 ` 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=1370231597.5988.79.camel@marge.simpson.net \
--to=efault@gmx.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®