Re: Regression seen for patch "sched:dont decrease idle sleep avg"

[Con Kolivas]

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

-- 
-ck
-
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/