Re: [REVIEW/TEST] nanodelay() vs DELAY()

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