Re: [SHED] Questions.

[Ian Kumlien <pomac@vapor.com>]

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

[Forgot to CC LKML last time, so i didn't remove old text ]

On Sun, 2003-08-31 at 12:57, Nick Piggin wrote:
> Ian Kumlien wrote:
> >On Sun, 2003-08-31 at 12:41, Nick Piggin wrote:
> >>Ian Kumlien wrote:
> >>>On Sun, 2003-08-31 at 12:17, Nick Piggin wrote:

> >>>>Search for "Nick's scheduler policy" ;)

> >>>Heh, yeah, i have been following your and con's work via
> >>>marc.theaimsgroup.com. =)

> >>Well, my patch does almost exactly what you describe.

> >Yes, i know =)... You and con should team up =)

> Heh, well we discuss stuff sometimes, but we disagree on things.
> Which is a good thing because now our eggs are in two baskets.

Yes, but sometimes it feels like a merger would be better... As long as
the propper quantum usage prevails =)

> >>>But wouldn't ingos off the shelf stuff work better with the quantum
> >>>values like that?

> >>That means more complexity and behaviour that is more difficult
> >>to trace. The interactivity stuff is already a monster to tune.

> >Oh, humm, how much did you change btw? =))

> Yeah quite a lot. Lots included removing the interactivity stuff.

Humm, yeah, that should work automatically with the "used the full
quantum" if thats still in that is... =)

> >>>And is the preempt min quantum in there?

> >>No. If you do that, you'll either break the priority concept very
> >>badly, or you'll break it a little bit and turn the scheduler into
> >>an O(n) one.

> >>Well I guess you could just break it a little bit without it being
> >>O(n)

> >Well, i just thought since each context switch/reschedule is costly...
> >Having something that prevents a freshly scheduled process from being
> >forced off before it can actually do something would be usefull.

> Yeah it is, but the process will still take a lot of the penalty,
> and if it is using a lot of CPU in context switching, then it will
> get a lower priority anyway. Possibly there could be a very small
> additional penalty per context switch, but so far it hasn't been
> a big problem AFAIK.

Well my idea was more... The highest pri gets MIN_QUANT and a preemt
can't happen faster than MIN_QUANT or so.. 
If i remember correctly, 2.6 spends much more time doing the actual
context switches (not time / context switch but amount during this
period). The new 1000 HZ thingy doesn't have to have that effect...

And since to many context switches are inefficient imho, some standoffs
would be good =)

-- 
Ian Kumlien <pomac@vapor.com>

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