On Tue, 2003-09-02 at 13:08, Nick Piggin wrote: > Ian Kumlien wrote: > >You could say that the problem the current scheduler has is that it's > >not allowed to starve anything, thats why we add stuff to give > >interactive bonus. But if it *was* allowed to starve but gave bonus to > >the starved processes that would make most of the interactive detection > >useless (yes, we still need the "didn't use their timeslice" bit and > >with a timeslice that gets smaller the higher the pri we'd automagically > >balance most processes). > > > >(As usual my assumptions might be really wrong...) > > First off, no general purpose scheduler should allow starvation depending > on your definition. The interactivity stuff, and even dynamic priorities > allow short term unfairness. When you reach a certain load you *have to* allow starvation. Ie, you can't work around it... All i say is that if we have a more relaxed method we might benefit from it. > Hmm... what else? The "didn't use their timeslice" thing is not > applicable: a new timeslice doesn't get handed out until the previous one > is used. The priorities thing is done based on how much sleeping the > process does. And not the amount of cpu consumed by the app / go? > Its funny, everyone seems to have very similar ideas that they are > expressing by describing different implementations they have in mind. Yes =), I'm mailing Con directly now as well, to save some unwanted traffic here =). I just hope that we'll reach a agreement somewhere about whats sane or not... Mail me if you're interested as well. -- Ian Kumlien