lkml.org 
[lkml]   [1999]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PATCH: POSIX 1003.1b timer minor fixes
> The i386 TSC gives the wrong answers in the presence of APM and
> eventually ACPI, due to slowing the clock to save power. I think the

Neither APM nor ACPI are answers to the power management problem. Doing
power management in the kernel, without running bios code or anything and
having cross-architecture drivers is.

> To argue against myself, it's possible on later x86s to disable
> user-space TSC, so it would be possible to trap the rdtsc instruction

on all x86s that implement TSC afaik.

> when the clock is slowed and substitute a suitably faked up value. That
> would only slow the execution path when the clock is slowed for power
> management -- at full speed it would be very fast.

When you use rdtsc in user code, you basically do:

do {
start = rdtsc();

<some code>

stop = rdtsc();
} while((stop - start) > HIGH_VALUE);

to ensure you were not interrupted so you get exact timing.

Now when you'd use a fake rdtsc value, you'd basically sacrifice any debugging
use of rdtsc for the very limited exact time case.

> To argue conversely again... can you have processors with different
> internal clocks (speed & value) in an SMP system?

On Alpha at least, the cycle counters of two CPUs do not run synchronously,
so yes. I don't know about any systems with different CPU speeds, but we
should not make it harder to use them if they exist.

Philipp Rumpf

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.041 / U:0.860 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site