Re: [SHED] Questions.

[Ian Kumlien <pomac@vapor.com>]

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]

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 <pomac@vapor.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]