Re: [SHED] Questions.
From: Ian Kumlien (pomac_at_vapor.com)
Date: 08/31/03
- Previous message: Andrey Borzenkov: "Re: Does sysfs really provides persistent hardware path to devices?"
- Maybe in reply to: Ian Kumlien: "[SHED] Questions."
- Next in thread: Nick Piggin: "Re: [SHED] Questions."
- Reply: Nick Piggin: "Re: [SHED] Questions."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: Nick Piggin <piggin@cyberone.com.au> Date: Sun, 31 Aug 2003 13:08:51 +0200
[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>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- application/pgp-signature attachment: This is a digitally signed message part
- Previous message: Andrey Borzenkov: "Re: Does sysfs really provides persistent hardware path to devices?"
- Maybe in reply to: Ian Kumlien: "[SHED] Questions."
- Next in thread: Nick Piggin: "Re: [SHED] Questions."
- Reply: Nick Piggin: "Re: [SHED] Questions."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
