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>