Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1700239

Re: wake_wide mechanism clarification

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: wake_wide mechanism clarification Joel Fernandes <joelaf@google.com> - 2017-07-29 10:10 +0200
  Re: wake_wide mechanism clarification Joel Fernandes <joelaf@google.com> - 2017-07-29 10:20 +0200
    Re: wake_wide mechanism clarification Michael Wang <yun.wang@profitbricks.com> - 2017-08-02 10:30 +0200
      Re: wake_wide mechanism clarification Joel Fernandes <joelaf@google.com> - 2017-08-04 01:50 +0200
  Re: wake_wide mechanism clarification Mike Galbraith <umgwanakikbuti@gmail.com> - 2017-07-29 17:10 +0200
    Re: wake_wide mechanism clarification Joel Fernandes <joelaf@google.com> - 2017-07-29 22:20 +0200
      Re: wake_wide mechanism clarification Joel Fernandes <joelaf@google.com> - 2017-07-30 00:30 +0200
        Re: wake_wide mechanism clarification Joel Fernandes <joelaf@google.com> - 2017-07-30 00:50 +0200
          Re: wake_wide mechanism clarification Josef Bacik <josef@toxicpanda.com> - 2017-07-31 14:30 +0200
            Re: wake_wide mechanism clarification Mike Galbraith <umgwanakikbuti@gmail.com> - 2017-07-31 15:50 +0200
              Re: wake_wide mechanism clarification Josef Bacik <josef@toxicpanda.com> - 2017-07-31 16:50 +0200
                Re: wake_wide mechanism clarification Mike Galbraith <umgwanakikbuti@gmail.com> - 2017-07-31 19:30 +0200
            Re: wake_wide mechanism clarification Joel Fernandes <joelaf@google.com> - 2017-07-31 18:30 +0200
              Re: wake_wide mechanism clarification Josef Bacik <josef@toxicpanda.com> - 2017-07-31 18:50 +0200
                Re: wake_wide mechanism clarification Joel Fernandes <joelaf@google.com> - 2017-07-31 20:00 +0200

csiph-web