Re: [RFC][PATCH][2.6.6] Replacing CPU scheduler active and expired with a single array

[Con Kolivas]

Quoting Peter Williams <pwil3058@xxxxxxxxxxxxxx>:

> 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@xxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/