Re: Regression seen for patch "sched:dont decrease idle sleep avg"
From: Con Kolivas
Date: Wed May 17 2006 - 20:35:45 EST
On Thursday 18 May 2006 05:33, Chen, Kenneth W wrote:
> The assignment of p->sleep_avg = ceiling doesn't make much logical sense.
> Because INTERACTIVE_SLEEP is scaled proportionally with nice value, e.g.
> the lower the nice value, the lower the interactive_sleep. However,
> priority calculation is inverse of p->sleep_avg, e.g. the smaller the
> sleep_avg, the smaller the bonus, thus the higher dynamic priority.
> Take one concrete example: for a prolonged sleep, say 1 second, nice(-10)
> will have a priority boost of 4 while nice(0) will have a priority boost of
> 9. The ceiling algorithm looks like is reversed. I would think kernel
> should at least enforce same ceiling value independent of nice value.
I see why you don't like it. However I still don't think you understand why
the ceiling of that magnitude is there. Tasks behave very differently
depending on whether their priority is low enough that they expire at the end
of every timeslice and get put on the expired array, or their priority is
high enough that they get reinserted into the active array. It's an intrinsic
quirk in the "interactive" design of the scheduler that basically means we
have two classes of task - interactive enough to be reinserted into the
active array or not. As the comment already says the ceiling is there to
prevent one sleep from getting them to best priority. I don't want them to
get high priority with one large enough sleep, but I do want them to get into
the reinsertion class which behaves entirely differently. What is missing
from the comment is to say that it is also designed to stop them at the
lowest possible priority that still keeps them in the interactive reinsertion
class. Using a constant ceiling value irrespective of nice will not guarantee
that tasks fall into the active reinsertion class dependant on their nice
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/