Messages in this thread | | | Date | Mon, 31 May 2004 09:13:32 +1000 | From | Con Kolivas <> | Subject | Re: [RFC][PATCH][2.6.6] Replacing CPU scheduler active and expired with a single array |
| |
Quoting Peter Williams <pwil3058@bigpond.net.au>:
> Con Kolivas wrote: > > The interactive credit? > > No. I was asking about the mechanism in schedule() that, based on the > value of "activated", allows some tasks to count their time on the run > queue as sleep time.
No this is different again. When there is significant load and an interactive task (like X) is using bursts of cpu it will not get a chance to sleep. It will either run out of timeslice or be preempted and thus will be constantly on the runqueue. In that time if only sleep time is counted it is progressively seen as a cpu bound task - in fact this was a major problem before where X would basically die under load because you'd move a window and it would be constantly waiting for more cpu time rather than ever sleeping.
> I also think that their is a category of task that may be automatically > detected and that needs special attention and that is tasks that need > very regular access to small bursts of CPU. I suspect that the tasks > doing the mpeg and divx encoding/decoding that you refer to above fall > into this category. The key to identifying these tasks would be that > the variance (or standard deviation) of their sleeps would be close to > zero and as they probably do much the same amount of work each CPU burst > the same would be true of the variance of the length of the CPU bursts.
I've already tried that experiment and I personally failed to make the pattern of sleep/burst correspond with interactivity. There is a huge variation in the duration of sleep/run for all different things, and it changes with load. Of course your modelling may be better than mine.
> Dr Peter Williams pwil3058@bigpond.net.au
Oooh I've got one of those too but I normally dont use it on lkml. So just for this once...
Dr Con Kolivas - 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/
| |