Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932081AbXAHUwY (ORCPT ); Mon, 8 Jan 2007 15:52:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932094AbXAHUwX (ORCPT ); Mon, 8 Jan 2007 15:52:23 -0500 Received: from terminus.zytor.com ([192.83.249.54]:44414 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932081AbXAHUwW (ORCPT ); Mon, 8 Jan 2007 15:52:22 -0500 Message-ID: <45A2AEE0.4090707@zytor.com> Date: Mon, 08 Jan 2007 12:51:44 -0800 From: "H. Peter Anvin" User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: Jan Engelhardt CC: dean gaudet , akpm@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] All Transmeta CPUs have constant TSCs References: <200701050148.l051mHGM005275@terminus.zytor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1549 Lines: 33 Jan Engelhardt wrote: > On Jan 8 2007 00:02, dean gaudet wrote: >> On Fri, 5 Jan 2007, Jan Engelhardt wrote: >>> On Jan 4 2007 17:48, H. Peter Anvin wrote: >>>> [i386] All Transmeta CPUs have constant TSCs >>>> All Transmeta CPUs ever produced have constant-rate TSCs. >>> A TSC is ticking according to the CPU frequency, is not it? >> transmeta decided years before intel and amd that a constant rate tsc >> (unaffected by P-state) was the only sane choice. on transmeta cpus the >> tsc increments at the maximum cpu frequency no matter what the P-state >> (and no matter what longrun is doing behind the kernel's back). >> >> mind you, many people thought this was a crazy choice at the time... >> > Well it defeats the purpose of TSC. I mean, they could have kept the "TSC" and > instead added a second TSC ticker, constant_tsc. > It depends on what "the purpose of TSC" is. The original spec is ambiguous if the TSC counts wall time or CPU time, since there was no distinction when the spec was made. The more common usage, however, was to count wall time; the relatively few users who care about CPU cycles (especially when the CPU is degraded) can be serviced via an RDPMC counter. I *definitely* support the concept that RDPMC 0 should could CPU cycles by convention in Linux. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/