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'sFirst off, no general purpose scheduler should allow starvation depending
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...)
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.