[REVIEW/TEST] nanodelay() vs DELAY()
Peter Jeremy
PeterJeremy at optushome.com.au
Sun Nov 21 23:31:38 PST 2004
On Fri, 2004-Nov-19 10:37:57 +0100, Poul-Henning Kamp wrote:
> http://phk.freebsd.dk/patch/nanodelay.patch
One buglet. In:
+static void
+initnanodelay(void *dummy)
+{
+ int i;
+
+ for (i = 0; i < N_NANODELAY_BUCKETS; i++) {
+ nanodelay_funcs[i] = tc_nanodelay;
+ nanodelay_args[i] = i;
+ }
The 2nd last line should be:
+ nanodelay_args[i] = i * (1 << N_NANODELAY_SHIFT);
because the argument to tc_nanodelay() is in nsec.
The fact that this doesn't show up in the graph suggests that you're
not using tc_nanodelay() at all within the 0..8usec range.
>Here is a plot which shows how DELAY() and nanodelay() perform on two
>of my test-machines:
>
> http://phk.freebsd.dk/misc/nanodelay.png
nanodelay() definitely looks much healthier than DELAY().
>A default routine spins on the timecounter using nanouptime(). How
>well this works depends on which timecounter we use, but in general
>we can trust it to be OK above a few microseconds.
Your graph suggests that it's fairly good above about 200nsec even on
equipment that is not blazingly fast.
Have you looked at the granularity of tc_nanodelay() (and the likely
granularity required by callers)? Is 8nsec reasonable given the
inner loop of of tc_nanodelay()?
Do you have any idea where the transition points between the various
delay functions are?
>The array takes up 9000 bytes on 32 bit and 17000 on 64 bit.
AFAIK, all the FreeBSD architectures have 32-bit ints, so that should
be 13,000 bytes for 64bit architectures.
--
Peter Jeremy
More information about the freebsd-arch
mailing list