mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: Josef Bacik <josef@toxicpanda.com>,
	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 14:48:07 +0000	[thread overview]
Message-ID: <20170731144806.GA7791@li70-116.members.linode.com> (raw)
In-Reply-To: <1501508545.6867.32.camel@gmail.com>

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.
 
> 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.  Now HZ may be an eternity
in scheduler time, but I think its a good middle ground.  For our case the box
is loaded constantly, so we basically never want affine wakeups for our app.
For the case where there's spikey behavior we'll return to normal affine wakeups
a short while later.

But from my admittedly limited testing it appears to be a win overall.  Thanks,

Josef

  reply	other threads:[~2017-07-31 14:48 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-30  0:19 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 [this message]
2017-07-31 17:23                         ` Mike Galbraith
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=20170731144806.GA7791@li70-116.members.linode.com \
    --to=josef@toxicpanda.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=linux-kernel@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=patrick.bellasi@arm.com \
    --cc=peterz@infradead.org \
    --cc=umgwanakikbuti@gmail.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®