[i386] All Transmeta CPUs have constant TSCs
All Transmeta CPUs ever produced have constant-rate TSCs.
Signed-off-by: H. Peter Anvin <[email protected]>
---
commit 07e54489ef8a3341b20ae42b53b1254a68061204
tree 204fa19fe2b2dd3ddb1add83ec66ccda7360f4e6
parent 7523c4dd9923cab748dad9b79d0165e118e3d03b
author H. Peter Anvin <[email protected]> Thu, 04 Jan 2007 17:44:34 -0800
committer H. Peter Anvin <[email protected]> Thu, 04 Jan 2007 17:44:34 -0800
arch/i386/kernel/cpu/transmeta.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/i386/kernel/cpu/transmeta.c b/arch/i386/kernel/cpu/transmeta.c
index 4056fb7..b536e81 100644
--- a/arch/i386/kernel/cpu/transmeta.c
+++ b/arch/i386/kernel/cpu/transmeta.c
@@ -72,6 +72,9 @@ static void __cpuinit init_transmeta(struct cpuinfo_x86 *c)
wrmsr(0x80860004, ~0, uk);
c->x86_capability[0] = cpuid_edx(0x00000001);
wrmsr(0x80860004, cap_mask, uk);
+
+ /* All Transmeta CPUs have a constant TSC */
+ set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
/* If we can run i686 user-space code, call us an i686 */
#define USER686 (X86_FEATURE_TSC|X86_FEATURE_CX8|X86_FEATURE_CMOV)
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?
-`J'
--
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...
-dean
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.
-`J'
--
Jan Engelhardt wrote:
> On Jan 8 2007 00:02, dean gaudet wrote:
>>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).
> Well it defeats the purpose of TSC. I mean, they could have kept the "TSC" and
> instead added a second TSC ticker, constant_tsc.
Given that the name is "time stamp counter" then it makes sense to me to
have a constant frequency.
For performance monitoring it would be useful to have a "cpu cycle
counter" that counts clock cycles, and varies (and possibly stops) with
the cpu itself.
Chris
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
On Mon, 8 Jan 2007, H. Peter Anvin wrote:
> I *definitely* support the concept that RDPMC 0 should could CPU cycles by
> convention in Linux.
unfortunately that'd be very limiting and annoying on core2 processors
which have dedicated perf counters for clocks unhalted (actual vs.
nominal), but only 2 configurable perf counters. i forget what ecx value
gets you the dedicated counters... but a solution which might work would
be a syscall to return the perf counter number...
or we could just merge perfmon ;)
-dean
dean gaudet wrote:
> On Mon, 8 Jan 2007, H. Peter Anvin wrote:
>
>> I *definitely* support the concept that RDPMC 0 should could CPU cycles by
>> convention in Linux.
>
> unfortunately that'd be very limiting and annoying on core2 processors
> which have dedicated perf counters for clocks unhalted (actual vs.
> nominal), but only 2 configurable perf counters. i forget what ecx value
> gets you the dedicated counters... but a solution which might work would
> be a syscall to return the perf counter number...
>
> or we could just merge perfmon ;)
>
OK, if there are dedicated counters in hardware at a different number,
we probably should make it an ELF entry value (no need to make it a
syscall for a constant.)
-hpa