From: Mike Galbraith <umgwanakikbuti@gmail.com>
To: Josef Bacik <josef@toxicpanda.com>
Cc: Joel Fernandes <joelaf@google.com>,
Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Juri Lelli <Juri.Lelli@arm.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Patrick Bellasi <patrick.bellasi@arm.com>,
Brendan Jackman <brendan.jackman@arm.com>,
Chris Redpath <Chris.Redpath@arm.com>,
Michael Wang <wangyun@linux.vnet.ibm.com>,
Matt Fleming <matt@codeblueprint.co.uk>
Subject: Re: wake_wide mechanism clarification
Date: Mon, 31 Jul 2017 19:23:46 +0200 [thread overview]
Message-ID: <1501521826.5348.12.camel@gmail.com> (raw)
In-Reply-To: <20170731144806.GA7791@li70-116.members.linode.com>
On Mon, 2017-07-31 at 14:48 +0000, Josef Bacik wrote:
> On Mon, Jul 31, 2017 at 03:42:25PM +0200, Mike Galbraith wrote:
> > On Mon, 2017-07-31 at 12:21 +0000, Josef Bacik wrote:
> > >
> > > I've been working in this area recently because of a cpu imbalance problem.
> > > Wake_wide() definitely makes it so we're waking affine way too often, but I
> > > think messing with wake_waide to solve that problem is the wrong solution. This
> > > is just a heuristic to see if we should wake affine, the simpler the better. I
> > > solved the problem of waking affine too often like this
> > >
> > > https://marc.info/?l=linux-kernel&m=150003849602535&w=2
> >
> > Wait a minute, that's not quite fair :) Wake_wide() can't be blamed
> > for causing too frequent affine wakeups when what it does is filter
> > some out. While it may not reject aggressively enough for you (why you
> > bent it up to be very aggressive), seems the problem from your loads
> > POV is the scheduler generally being too eager to bounce.
> >
>
> Yeah sorry, I hate this stuff because it's so hard to talk about without mixing
> up different ideas. I should say the scheduler in general prefers to wake
> affine super hard, and wake_wide() is conservative in it's filtering of this
> behavior. The rest still holds true, I think tinkering with it is just hard and
> the wrong place to do it, it's a good first step, and we can be smarter further
> down.
Yeah, it's hard, and yeah, bottom line remains unchanged.
> > I've also played with rate limiting migration per task, but it had
> > negative effects too: when idle/periodic balance pulls buddies apart,
> > rate limiting inhibits them quickly finding each other again, making
> > undoing all that hard load balancer work a throughput win. Sigh.
> >
>
> That's why I did the HZ thing, we don't touch the task for HZ to let things
> settle out, and then allow affine wakeups after that.
I kinda like the way you did it better than what I tried, but until a
means exists to _target_ the win, it's gonna be rob Peter to pay Paul,
swap rolls, repeat endlessly.
-Mike
next prev parent reply other threads:[~2017-07-31 17:23 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-30 0:19 wake_wide mechanism clarification Joel Fernandes
2017-06-30 0:49 ` Josef Bacik
2017-06-30 3:04 ` Joel Fernandes
2017-06-30 14:28 ` Josef Bacik
2017-06-30 17:02 ` Mike Galbraith
2017-06-30 17:55 ` Josef Bacik
2017-08-03 10:53 ` Brendan Jackman
2017-08-03 13:15 ` Josef Bacik
2017-08-03 15:05 ` Brendan Jackman
2017-08-09 21:22 ` Atish Patra
2017-08-10 9:48 ` Brendan Jackman
2017-08-10 17:41 ` Atish Patra
2017-07-29 8:01 ` Joel Fernandes
2017-07-29 8:13 ` Joel Fernandes
2017-08-02 8:26 ` Michael Wang
2017-08-03 23:48 ` Joel Fernandes
2017-07-29 15:07 ` Mike Galbraith
2017-07-29 20:19 ` Joel Fernandes
2017-07-29 22:28 ` Joel Fernandes
2017-07-29 22:41 ` Joel Fernandes
2017-07-31 12:21 ` Josef Bacik
2017-07-31 13:42 ` Mike Galbraith
2017-07-31 14:48 ` Josef Bacik
2017-07-31 17:23 ` Mike Galbraith [this message]
2017-07-31 16:21 ` Joel Fernandes
2017-07-31 16:42 ` Josef Bacik
2017-07-31 17:55 ` Joel Fernandes
2017-06-30 3:11 ` Mike Galbraith
2017-06-30 13:11 ` Matt Fleming
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=1501521826.5348.12.camel@gmail.com \
--to=umgwanakikbuti@gmail.com \
--cc=Chris.Redpath@arm.com \
--cc=Juri.Lelli@arm.com \
--cc=brendan.jackman@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=joelaf@google.com \
--cc=josef@toxicpanda.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=patrick.bellasi@arm.com \
--cc=peterz@infradead.org \
--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.