Date: Tue, 18 Oct 2005 20:05:27 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Nate Lawson <nate@root.org> Cc: Scott Long <scottl@samsco.org>, src-committers@FreeBSD.org, Andrew Gallatin <gallatin@cs.duke.edu>, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, David Xu <davidxu@FreeBSD.org> Subject: Re: cvs commit: src/sys/amd64/amd64 cpu_switch.S machdep.c Message-ID: <69633.1129658727@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 18 Oct 2005 10:31:14 PDT." <43553162.5040802@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <43553162.5040802@root.org>, Nate Lawson writes: >> The TSC represents the clock rate of the CPU, and thus can vary wildly >> when thermal and power management controls kick in, and there is no way >> to know when it changes. Because of this, I think that it's >> practically useless on Pentium-Mobile and Pentium-M chips, among many >> others. > >This is a myth. It isn't a myth. As recent as this year chips have been sent on the market which will throttle their cpu-clock and TSC on certain chip stress conditions without giving any timely indication to any part of the BIOS or OS. One major BIOS supplier still mucks up SMP TSC synchronization on certain SMM bios actions. And remember: not everybody runs intel or AMD chips. We need to work on sparc64 and alpha chips as well. Alpha is particularly nasty as some of the older chips have a SAW generated CPU clock which is not synchronized to the bus clock. >> There is also the issue of multiple CPUs having to keep their >> TSC's somewhat in sync in order to get consistent counting in the >> system. For "somewhat" read: "exact" Unless we want to do the Lamport-trick and pay the overhead of intra-cpu locks when we calculate timestamps they have to be in _exact_ synchronization _and_ syntonization. The solution to the context switch problem is _not_ to botch the timekeeping, the solution is to not _need_ the timekeeping. -- 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?69633.1129658727>