Messages in this thread | | | Date | Thu, 29 Jul 1999 00:38:35 +0200 | From | Philipp Rumpf <> | Subject | Re: 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/
| |