Re: [SHED] Questions.

From: Ian Kumlien
Date: Sun Aug 31 2003 - 17:43:31 EST


On Sun, 2003-08-31 at 21:51, Robert Love wrote:
> On Sun, 2003-08-31 at 15:31, Ian Kumlien wrote:
>
> > Since they would have a high pri still, and preempt is there... it
> > should be back on the cpu pretty quick.
>
> Ah, but no! You assume we do not have an expired list and round robin
> scheduling.

hummm, I assume that a high pri process can preempt a low pri process...
The rest sounds sane to me =), Please tell me what i'm missing.. =)

> Once a task exhausts its timeslice, it cannot run until all other tasks
> exhaust their timeslice. If this were not the case, high priority tasks
> could monopolize the system.

All other? including sleeping?... How many tasks can be assumed to run
on the cpu at a time?....

Should preempt send the new quantum value to all "low pri, high quantum"
processes?

Damn thats a tough cookie, i still think that the priority inversion is
bad. Don't know enough about this to actually provide a solution...
Any one else that has a view point?

> > But, it also creates problems for when a interactive process becomes a
> > cpu hog. Like this the detection should be faster, but should be slowed
> > down somewhat.
>
> I agree, although I do think it responds fairly quick. But, regardless,
> this is why I am interested in Nick's work. The interactivity estimator
> can never be perfect.

Hummm, the skips in xmms tells me that something is bad..
(esp since it works perfectly on the previus scheduler)

> > But, hogs would instead cause a context switch hell and lessen the
> > throughput on server loads...
>
> Hm, why?

Since it's rescheduled after a short runtime or, might be.
From someones mail i saw (afair), there was much more context switches
in 2.6 than in 2.4. And each schedule consumes time and cycles.

> > I don't see how priorities would be questioned... Since, all i say is
> > that a task that gets preempted should have a guaranteed time on the cpu
> > so that we don't waste cycles doing context switches all the time.
>
> But latency is important.

Oh yes, but otoh, if you are really keen on the latency then you'll do
realtime =)

--
Ian Kumlien <pomac@xxxxxxxxx>

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