Date: Tue, 18 Oct 2005 14:38:29 -0700 From: Nate Lawson <nate@root.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> 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: <43556B55.9020401@root.org> In-Reply-To: <69633.1129658727@critter.freebsd.dk> References: <69633.1129658727@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote: > 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. Does this refer to the p4tcc platform limit that I described or is it soemthing different? In my analysis, the limit is set very high and should not be hit unless a fan fails. This info seems to match my observations: "Thermal Monitor controls the processor temperature by modulating (starting and stopping) the processor core clocks. Automatic and On-Demand modes are used to activate the thermal control circuit (TCC). When automatic mode is enabled, the TCC will activate only when the interanl die temperature is very near the temperature limits of the processor." http://www.intel.com/cd/channel/reseller/asmo-na/eng/products/box_processors/mobile/celeron_m/technical_reference/97374.htm For Prescott, the temp for automatic cut-in is around 72C. We may be able to detect this on SMP systems via IPIs (I don't know which ones). http://softwareforums.intel.com/ids/board/message?board.id=49&message.id=456 That doesn't mean we can ignore it, just that we don't have to optimize for that case. When your CPU is about to melt down, having slower scheduling for a few seconds doesn't seem unreasonable. > The solution to the context switch problem is _not_ to botch > the timekeeping, the solution is to not _need_ the timekeeping. Yes, I agree. We need to fix context switching to not be binuptime()-based and separately improve TSC support so it can be used more often as a timecounter. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43556B55.9020401>