Messages in this thread | | | Subject | Re: [SHED] Questions. | From | Ian Kumlien <> | Date | Sun, 31 Aug 2003 13:43:28 +0200 |
| |
On Sun, 2003-08-31 at 13:31, Nick Piggin wrote: > Ian Kumlien wrote: > > >[Forgot to CC LKML last time, so i didn't remove old text ] > > > >On Sun, 2003-08-31 at 12:57, Nick Piggin wrote: > > > > > >>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 =)
> Nope. They're going in different directions. We'd slow each other down.
Okis.
> >>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... =) > > > > You've lost me here. > My stuff is the opposite of what the interactivity stuff is trying > to do. The interactivity stuff _does_ kind of implement variable > timeslices in the form of re queueing stuff. I think it would be a > nightmare for them to put my variable timeslices on top of that and > then get it to all work properly.
Well, i dunno how your patch works (i forget =))... But afair ingos interactivity patches was about the amount of the quantum that was used. And combining that with high = small and low = large would automatically balance the priorities accordingly.
> >>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.. > > > > My idea is to try to make it as simple as possible, and no > simpler (as a great man put it!). So more is less if you > know what I mean.
Yup =)
> I think this is going against how the scheduler (and UNIX > schedulers in general) have generally behaved. Its very likely > that you'd be better off fixing your app / other broken bit > of kernel code though. > > I don't know... maybe...
Humm i thought more in the direction of: Preempt prior to MIN_QUANT being used -> put it on the runqueue as the next process being scheduled, change the running tasks timeslice -> continue with current task.
(make the current tasks timeslice appear as used.)
> >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 =) > > > > I'm not sure. I think the 1000HZ thing is mainly from timer interrupts. > The scheduler should be pretty well agnostic to the 100->1000 change, > other than having higher resolution. Increased context switches might > indicate something is not being scaled with HZ properly though.
hummm i dunno, but afair the scheduler uses that timing aswell...
> Yes context switches are inefficient. The tradeoff is vs scheduling > latency and there is no way around that.
Thus, keeping preempt from being able to preempt other tasks prior to MIN_QUANT being used is bad.. =)
Which also might fix the "child preempting parent on fork" problem that con patched afair. (dunno if you have the same problem though...)
-- Ian Kumlien <pomac@vapor.com> [unhandled content-type:application/pgp-signature] | |