I don't know how fast the CPU clock is running during the handler, but I
do know it slows down the clock by a factor of 4 to save power
sometimes, and the clock rate cannot change instantaneously because of
PLL synchronisation time in the CPU (I think it takes a few milliseconds
to change the clock rate, gradually). So I would expect that the
interrupt handler runs at the slowed clock rate, at least for a while.
For more than a jiffy.
>From my limited understanding of arch/i386/kernel/entry.S, bottom
halves, signal handlers and even a rescheduled process would all be
considered part of handling the interrupt by the BIOS, even with
hardware support. These things need to read the time.
C. Scott Ananian wrote:
> +/* Tell fast_gettimeoffset that the tsc is invalid. Doesn't hurt even if
> + * the tsc is not present. */
> +void invalidate_tsc(void) { stale_jiffies = jiffies; }
... and later calls to invalidate_tsc() in drivers/char/apm_bios.c after
the APM driver requests suspend/standby/idle state.
Does this mean the TSC is considered reliable after it is next read in a
timer interrupt? It seems to me, that the TSC can remain unreliable for
a while after the next timer interrupt, perhaps because the clock is
slowed, or maybe worse in the sleeping state between interrupt handlers.
Perhaps it is even unreliable for many jiffies, if the sleeping state
persists for a long time in which timer interrupts are processed.
Possibly kernel APM support needs to tell the BIOS "actually I'm busy
now" if the interrupt return is via a bottom half, reschedule etc.
Maybe it does already (I couldn't tell).
I would guess that the TSC should be considered unreliable until the APM
code has done it's regular 1 second checking thing and ensured the
system is in a busy state. That's just a wild guess, mind.
I don't know much about this, just passing on what is mentioned in my
manual.
-- Jamie
-
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.altern.org/andrebalsa/doc/lkml-faq.html