> On Fri, 15 Jan 1999, Gabriel Paubert wrote:
>
> >It furiously looks like an off by one error (or an < versus <=
> >comparison, or a postfix versus prefix increment or decrement)
> >which would give actually 2 and 21 slices rather than 1 and 20:
> >
> > 2/23 ~= 8.7 %
> >21/23 ~= 91.3 %
>
> It's an off-by-one difference, but not an 'error'.
> You get:
> nice +19 = 1 slice (nice +20 doesn't exist, at least not in 2.0.x)
> nice +0 = 20 slices
> But the linux scheduler can choose to run for a slice even processes
> with 0 slices left if there are no processes with higher counter.
> So you get the +1 bias you say, in agreement with the numbers 8.7% / 91.3%.
Sorry, I did not state clearly what I meant. By error I meant either an
off by one in Neil's understanding of the code or a behaviour which does
not correspond with the idea of the scheduler author.
Nevertheless, I think that around 9% of CPU for a maximally niced process
is still too high. Basically this 'off by one' thing decreases the dynamic
range in priority adjustment by a factor of 2 which is not negligible
IMHO. But it depends mostly on how it scales with several niced processes,
will 4 number-crunching niced processes take 8/29 ~= 28% of CPU time (on
an UP box) ?
Gabriel
P.S: while wrinting a patch by Ingo came along which at leasts makes the
comments consistent with the implementation. That's at the very least
what I liked to see.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/