Messages in this thread | | | Subject | Re: [RFC][PATCH] sched: Avoid select_idle_sibling() for wake_affine(.sync=true) | From | Mike Galbraith <> | Date | Thu, 26 Sep 2013 07:34:48 +0200 |
| |
On Thu, 2013-09-26 at 13:12 +0800, Michael wang wrote: > On 09/26/2013 11:41 AM, Mike Galbraith wrote: > [snip] > >> Like the case when we have: > >> > >> core0 sg core1 sg > >> cpu0 cpu1 cpu2 cpu3 > >> waker busy idle idle > >> > >> If the sync wakeup was on cpu0, we can: > >> > >> 1. choose cpu in core1 sg like we did usually > >> some overhead but tend to make the load a little balance > >> core0 sg core1 sg > >> cpu0 cpu1 cpu2 cpu3 > >> idle busy wakee idle > > > > Reducing latency and increasing throughput when the waker isn't really > > really going to immediately schedule off as the hint implies. Nice for > > bursty loads and ramp. > > > > The breakeven point is going up though. If you don't have nohz > > throttled, you eat tick start/stop overhead, and the menu governor > > recently added yet more overhead, so maybe we should say hell with it. > > Exactly, more and more factors to be considered, we say things get > balanced but actually it's not the best choice... > > > > >> 2. choose cpu0 like the patch proposed > >> no overhead but tend to make the load a little more unbalance > >> core0 sg core1 sg > >> cpu0 cpu1 cpu2 cpu3 > >> wakee busy idle idle > >> > >> May be we should add a higher scope load balance check in wake_affine(), > >> but that means higher overhead which is just what the patch want to > >> reduce... > > > > Yeah, more overhead is the last thing we need. > > > >> What about some discount for sync case inside select_idle_sibling()? > >> For example we consider sync cpu as idle and prefer it more than the others? > > > > That's what the sync hint does. Problem is, it's a hint. If it were > > truth, there would be no point in calling select_idle_sibling(). > > Just wondering if the hint was wrong in most of the time, then why don't > we remove it...
For very fast/light network ping-pong micro-benchmarks, it is right. For pipe-test, it's absolutely right, jabbering parties are 100% synchronous, there is nada/nil/zip/diddly squat overlap reclaimable.. but in the real world, it ain't necessarily so.
> Otherwise I think we can still utilize it to make some decision tends to > be correct, don't we?
Sometimes :)
-Mike
| |