On Mon, Jul 13, 2015 at 02:30:38PM +0200, Mike Galbraith wrote: > On Mon, 2015-07-13 at 20:07 +0900, Byungchul Park wrote: > > > i still think stretching with local cfs's nr_running should be replaced with > > stretching with a top(=root) level one. > > I think we just can't take 'slice' _too_ seriously. Not only is it
hello mike, :) as you said, it is not too much important thing which has to be taken too seriously, since it would be adjusted by vruntime in cfs. but.. is there any reason meaningless code should be kept in source? :( it also harms readability. of cource, i need to modify my patch a little bit to prevent non-group sched entities from getting large slice. thank you, byungchul > annoying with cgroups, the scheduler simply doesn't deliver 'slices' in > the traditional sense, it equalizes vruntimes, planning to do that at > slice granularity. FAIR_SLEEPERS doesn't make that planning any easier. > With a pure compute load and no HR_TICK, what you get is tick > granularity preemption checkpoints, but having just chewed up a 'slice' > means nothing if you're still leftmost. It's all about vruntime, so > leftmost can have back to back 'slices'. FAIR_SLEEPERS just increases > the odds that leftmost WILL take more than one 'slice'. > > (we could perhaps decay deficit after a full slice or such to decrease > the spread growth that sleepers induce. annoying problem, especially so > with a gaggle of identical sleepers, as sleep time becomes meaningless, > there is no differential to equalize.. other than the ones we create.. > but I'm digressing, a lot, time to stop thinking/typing, go do work;) > > -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/ -- 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/
