Re: Scheduler degradation since 2.5.66
From: Bill Davidsen
Date: Wed Jan 14 2004 - 19:49:58 EST
George Anzinger wrote:
We get the request at some time t between tick tt and tt+1 to sleep for
N ticks.
We round this up to the next higher tick count convert to jiffies
dropping any fraction and then add 1. So that should be 2 right? This
is added to NOW which, in the test code, is pretty well pined to the
last tick plus processing time. So why do you see 3?
What is missing here is that the request was for 1.000000 ms and a tick
is really 0.999849 ms. So the request is for a bit more than a tick
which we are obligated to round up to 2 ticks. Then adding the 1 tick
guard we get the 3 you are seeing. Now if you actually look at that
elapsed time you should see it at about 2.999547 ms and ranging down to
1.999698 ms.
Clearly the rounding between what you want and the resolution of the
hardware tick is never going to be perfect if there is a non-integer
ratio between the values. If this is a real concern, you can play with
the algorithm and/or go to a faster clock. Or both.
You might also be much happier simply setting target times 2ms apart,
and sleeping for target-NOW ns. That allows for the processing time.
If the kernel had a better idea of when the next tick would be instead
of assuming counting from NOW instead of "last tick" you could probably
do better, but I'm not suggesting that overhead be added to the ticks
code in case someone needs a better nanosleep. I don't know how well
that would work in the SMP case in any event. Sort of
wait_ticks = 1 + int((NOW + delay - time_since_last_tick)/ns_per_tick)
or
wait_ticks =
int((NOW-delay - time_since_tick + ns_per_tick - 1)/ns_per_tick)
I think there's too much caution about going over, but without playing
with the code I'm just dropping ideas.
--
bill davidsen <davidsen@xxxxxxx>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
-
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/