Jamie Lokier wrote:
> 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.
Note that the CPU may be running at any clock frequency to save power, but the
timer interrupts will still arrive at the fixed 100 Hz. The 8253/82C54 CTC is
not affected by power saving.
> 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.
Do they read the system time (xtime) or do they call gettimeofday()?
*That* is the question.
If they read xtime, then no problem: xtime gets updated at jiffy intervals
anyways. And we still have the reliable jiffy interrupt coming at a fixed
frequency.
Things get more complicated if these routines call gettimeofday(). There are
two cases to consider here:
1) If these routines are calling gettimeofday() just
because they need _ordered_ events, no problem (except the non-unique timestamp
possibility, but that's another issue altogether, and nobody seems to care
about it anyways). Whether the CPU is running at full speed or slow as molasses,
we still get ordered timestamps.
2) If these routines are calling gettimeofday() to get very accurate time
interval data (i.e. because for example they need to use a very precise timing
for some hardware task), then we really have a problem.
(Note also that the "bogomips method" busy loop used to wait for small time
intervals is a no-no if your CPU is slowed down. If you are running at 1/4 CPU
clock, you are getting 4x longer intervals... busy waiting in the kernel. But
that has nothing to do with the new time.c code.)
The only routines I know of in the kernel that need this very accurate
information are the profiling routines. The obvious conclusion is that you
shouldn't do profiling with APM turned on. That seems quite logical, IMHO.
> 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.
Scott has included extra code that is supposed to tell the kernel when the TSC
is considered reliable and when it is not. Remember this was experimental code
that Scott hasn't had time to test.
I didn't include this code in the 2.0.3x version I posted to the list because I
don't feel it's needed. I haven't had any problems with the 2.0.3x version,
while running it for 45 days. IMHO we can do without the extra complexity, in
this case.
But perhaps my assumption is wrong? I guess that's why the code was posted to
the list: so that people can test it and help find the flaws/problems :-)
Time, especially when you start using the TSC to measure it, is a complex kernel
issue. Hence the caveat by Scott. Check the last question in the faq. It points
to a doc I wrote on this issue.
Cheers,
---------------------
Andrew D. Balsa
andrebalsa@altern.org
-
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