Messages in this thread | | | Subject | Re: [RFC PATCH 00/11] sched: CFS low-latency features | From | Mike Galbraith <> | Date | Fri, 27 Aug 2010 10:19:52 +0200 |
| |
On Fri, 2010-08-27 at 09:42 +0200, Peter Zijlstra wrote: > On Thu, 2010-08-26 at 19:49 -0400, Mathieu Desnoyers wrote: > > AFAIK, I don't think we would end up starving the system in any possible way. > > Correct, it does maintain fairness. > > > So far I cannot see a situation where selecting the next buddy would _not_ make > > sense in any kind of input-driven wakeups (interactive, timer, disk, network, > > etc). But maybe it's just a lack of imagination on my part. > > The risk is that you end up with always using next-buddy, and we tried > that a while back and that didn't work well for some, Mike might > remember.
I turned it off because it was ripping spread apart badly, and last buddy did a better job of improving scalability without it.
> Also, when you use timers things like time-outs you really couldn't care > less if its handled sooner rather than later. > > Disk is usually so slow you really don't want to consider it > interactive, but then sometimes you might,.. its a really hard problem.
(very hard)
> The only clear situation is the direct input, that's a direct link > between the user and our wakeup chain and the user is always important.
Yeah, directly linked wakeups using next could be a good thing, but the trouble with using any linkage to the user is that you have to pass it on to reap benefit.. so when do you disconnect?
-Mike
| |