Call for performance evaluation: net.isr.direct (fwd)

[Bruce Evans]

On Fri, 14 Oct 2005, Poul-Henning Kamp wrote:

> In message <17232.1207.615226.432579 at grasshopper.cs.duke.edu>, Andrew Gallatin
> writes:
>>
>> Poul-Henning Kamp writes:
>>> The solution is not faster but less reliable timekeeping, the
>>> solution is to move the scheduler(s) away from using time as an
>>> approximation of cpu cycles.
>>
>> So you mean rather than use binuptime() in mi_switch(), use some
>> per-cpu cycle counter (like rdtsc)?
>
> yes.

No.  This would just break getrusage(2) and friends.

>> Heck, why not just use ticks for the scheduler and keep the expensive
>> timekeeping code out of the critical path altogether?  Does it really
>> need better than 1ms resolution?

The schedulers already just use ticks (actually dynamic calls from
statclock() to count ticks and do other things).  Schedulers don't
need anywhere near 1ms resolution, and have never used 1ms resolution,
and haven't used 1/HZ resolution since FreeBSD-1/Net/3.  Use of 1/HZ
resolution went away with statclock.  statclock normally gives 1/128
seconds resolution, but even this is too high for the algorithm in
SCHED_4BSD, and that scheduler now scales it down to 1/16 seconds
resolution except for fine tuning.

Schedulers do this because a resolution of better than a tick was both
unavailable on all hardware and would have been to inefficient if it
was back when 1/100 seconds was a long time, and no one churned this
part of their algorithm.

> Because the resource accounting needs to know how much cpu power
> each process/thread has used, and the units used assume a constant
> clockrate (see times(3))

I was only thinking of kernel schedulers when I wrote the above.
Userland schedulers might have to use times(3) or friends.  They would
use friends and not times(3) since according to its own man page
times(3) was obsoleteted by getrusage(2) about 20 years ago.  The main
reason that it was obsoleted was that its wrong units are actually
ticks.  Its ticks used to be hardclock ticks, the same ones that the
scheduler used.  There were few problems with the rate of these -- the
rate was just that of hardclock(), so it was 1/HZ with considerable
jitter on old machines (because 1/HZ seconds was a short time on old
machines).  Now its units are ticks of length 1/CLK_TCK seconds, where
CLK_TCK happens to be implemented as a compile-time constant that is
always 128.  We start with the high resolution units provided by
timecounters and lose precision in several layers to support the old
times(3) API.  There are no real ticks invololved, only virtual ones
in the times(3) layer.

The constant clock rate for schedulers is still provided by statclock()
having a constant rate.  I believe it's actually a bug for this rate
to be constant -- it is supposed to have jitter so that applications
can't hide from statclock ticks.

Bruce