On Thu, 2013-09-26 at 07:34 +0200, Mike Galbraith wrote: > 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 :)
P.S. while we're slapping select_idle_sibling()'s _evil_ face, let's give it a pat on the head too. It showed regressions in bright red. Put pipe-test on one core, you only see scheduler weight.. but entering and exiting idle is part of the fast path, whether you're exercising it by doing something silly or not. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
