Date: Mon, 12 Dec 2005 15:31:40 -0800 From: Peter Wemm <peter@wemm.org> To: src-committers@freebsd.org Cc: cvs-src@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/amd64/isa clock.c Message-ID: <200512121531.40497.peter@wemm.org> In-Reply-To: <200512122227.jBCMR8SJ087111@repoman.freebsd.org> References: <200512122227.jBCMR8SJ087111@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 12 December 2005 02:27 pm, you wrote: > Modified files: > sys/amd64/isa clock.c > Log: > For the amd64 platform, we can depend on the TSC being present. > This patch changes DELAY to use the TSC once it has been calibrated. > This does NOT use the TSC for long-term timekeeping. It only uses > it to bound the DELAY() spinloop. This should not be affected by the > Athlon64 X2 TSC quirks because the cpu is not halted while we use > DELAY(). > > Revision Changes Path > 1.223 +15 -0 src/sys/amd64/isa/clock.c My intentions are to merge a variant of this to i386, then replace DELAY() on amd64 entirely. One key advantage to this way of doing DELAY() is that the new code does not aquire a mtx_spin lock. And mtx_spin locks can call DELAY(). This Can Be Bad(TM). Only i386/amd64/pc98 have a DELAY implementation that does this. All the other plaforms have a DELAY() with no internal spinlocks. This effectively brings amd64 (and later i386) into line with the other platforms. Old i386 machines with no TSC (or broken TSC) won't use it, but since they can't run SMP, spinlocks should mostly be a NOP and the mtx_lock_spin() -> DELAY() -> getit() -> mtx_lock_spin() problem should be a non-event on those machines. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200512121531.40497.peter>