Re: [SHED] Questions.

[Nick Piggin]

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.

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

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

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

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

Yes context switches are inefficient. The tradeoff is vs scheduling
latency and there is no way around that.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/