Date: Sat, 15 Oct 2005 10:21:56 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Garrett Wollman <wollman@csail.mit.edu>, Andrew Gallatin <gallatin@cs.duke.edu>, net@freebsd.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) Message-ID: <20051015094922.J1586@epsplex.bde.org> In-Reply-To: <33011.1129318588@critter.freebsd.dk> References: <33011.1129318588@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Oct 2005, Poul-Henning Kamp wrote: > In message <17232.1207.615226.432579@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051015094922.J1586>