lkml.org 
[lkml]   [2000]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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/

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