Re: [SHED] Questions.

[Ian Kumlien]

On Tue, 2003-09-02 at 02:23, Con Kolivas wrote:
> On Tue, 2 Sep 2003 09:03, Ian Kumlien wrote:
> > On Mon, 2003-09-01 at 17:07, Daniel Phillips wrote:
> > > IMHO, this minor change will provide a more solid, predictable base for
> > > Con and Nick's dynamic priority and dynamic timeslice experiments.
> >
> > Most definitely.
> 
> No, the correct answer is maybe... if after it's redesigned and put through 
> lots of testing to ensure it doesn't create other regressions. I'm not saying 
> it isn't correct, just that it's a major architectural change you're 
> promoting. Now isn't the time for that.
> 
> Why not just wait till 2.6.10 and plop in a new scheduler a'la dropping in a 
> new vm into 2.4.10... <sigh> 

Wouldn't a new scheduler be easier to test? And your patches changes
it's behavior quite a lot. Wouldn't they require the same testing?
(And Nicks for that mater, who changes more)

> The cpu scheduler simply isn't broken as the people on this mailing list seem 
> to think it is. While my tweaks _look_ large, they're really just tweaking 
> the way the numbers feed back into a basically unchanged design. All the 
> incremental changes have been modifying the same small sections of sched.c 
> over and over again. Nick's changes change the size of timeslices and the 
> priority variation in a much more fundamental way but still use the basic 
> architecture of the scheduler. 

But, can't this scheduler suffer from starvation? If the run queue is
long enough? Either via that deadline or via processes not running...

Wouldn't a starved process boost ensure that even hogs on a loaded
system got their share now and then?

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...)

> Promoting a new scheduler design entirely is admirable and ultimately probably 
> worth pursuing but not 2.6 stuff.

Well, discussing and creating it is one thing. Implementing it is
another. Accepting the patch is still up to the-powers-that-be(tm)

-- 
Ian Kumlien <pomac@xxxxxxxxx>

Attachment: signature.asc
Description: This is a digitally signed message part