Date: Wed, 24 Nov 2004 09:40:49 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Peter Jeremy <PeterJeremy@optushome.com.au> Cc: current@freebsd.org Subject: Re: [REVIEW/TEST] nanodelay() vs DELAY() Message-ID: <61435.1101285649@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 22 Nov 2004 18:31:32 %2B1100." <20041122073132.GW79646@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20041122073132.GW79646@cirb503493.alcatel.com.au>, Peter Jeremy wri tes: >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. Right, but I can't trust that to be the case as CPUs get faster. Originally I considered having MD routines registered also, stuff like doing an "inb()" on i386 etc. As it transpired the exponential nature of the nanodelay_loopcall2() function makes this unnecessary. >Your graph suggests that it's fairly good above about 200nsec even on >equipment that is not blazingly fast. Don't let the log-log scale deceive you. being 50% wrong doesn't look like much. >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()? I'm actually considering making it 32nsec based on a 33MHz PCI speed. >Do you have any idea where the transition points between the various >delay functions are? If you boot -v it will tell you. >>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. Still, that's an awful lot for an old ass'y programmer like me :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?61435.1101285649>