Rik van Riel wrote:
>
> On Thu, 12 Apr 2001, Pavel Machek wrote:
>
> > > One rule of optimization is to move any code you can outside the loop.
> > > Why isn't the nice_to_ticks calculation done when nice is changed
> > > instead of EVERY recalc.? I guess another way to ask this is, who needs
> >
> > This way change is localized very nicely, and it is "obviously right".
>
> Except for two obvious things:
>
> 1. we need to load the nice level anyway
> 2. a shift takes less cycles than a load on most
> CPUs
>
Gosh, what am I missing here? I think "top" and "ps" want to see the
"nice" value so it needs to be available and since the NICE_TO_TICK()
function looses information (i.e. is not reversible) we can not compute
it from ticks. Still, yes we need to load something, but is it nice?
Why not the result of the NICE_TO_TICK()?
A shift and a subtract are fast, yes, but this loop runs over all tasks
(not just the run list). This loop can put a real dent in preemption
times AND the notion of turning on interrupts while it is done can run
into some interesting race conditions. (This is why the MontaVista
scheduler does the loop without dropping the lock, AFTER optimizing the
h... out of it.)
What am I missing?
George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/