Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Nov 2004 18:31:32 +1100
From:      Peter Jeremy <PeterJeremy@optushome.com.au>
To:        Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc:        current@freebsd.org
Subject:   Re: [REVIEW/TEST] nanodelay() vs DELAY()
Message-ID:  <20041122073132.GW79646@cirb503493.alcatel.com.au>
In-Reply-To: <76633.1100857077@critter.freebsd.dk>
References:  <76633.1100857077@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041122073132.GW79646>