Messages in this thread | | | From | Borislav Deianov <> | Date | Thu, 9 Mar 2000 21:22:55 +0100 | Subject | Re: [PATCH] Use of TSC with SMP and different CPU's |
| |
On Thu, Mar 09, 2000 at 01:37:47PM -0500, Boris Okun wrote: > Borislav Deianov wrote: > > One question (I haven't looked at your patch): can it deal gracefully > > with suspending the machine, turning it off, then resuming? I don't > > think that you can do that yet on SMP but I hope that you soon will > > (ACPI or the software suspend patch). > > I don't think it can, and I don't think the current code can either.
There's this comment in the current code:
/* * If we have APM enabled or the CPU clock speed is variable * (CPU stops clock on HLT or slows clock to save power) * then the TSC timestamps may diverge by up to 1 jiffy from * 'real time' but nothing will break. * The most frequent case is that the CPU is "woken" from a halt * state by the timer interrupt itself, so we get 0 error. In the * rare cases where a driver would "wake" the CPU and request a * timestamp, the maximum error is < 1 jiffy. But timestamps are * still perfectly ordered. * Note that the TSC counter will be reset if APM suspends * to disk; this won't break the kernel, though, 'cuz we're * smart. See arch/i386/kernel/apm.c. */
That sounds good, on the other hand I can't convince myself that it's true. In do_fast_gettimeoffset we unconditionally use last_tsc_low which is set only in timer_interrupt. So what happens if we wake up and call do_gettimeofday before a time interrupt happens? Can't we overshoot by seconds because last_tsc_low is wildly wrong? Basically, I expected to see something in apm.c that sets last_tsc_low after suspend, and I don't.
Regards, Borislav
- 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/
| |