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 -- 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/
