On Thu, Sep 01, 2005 at 09:42:23AM +0200, Thomas Schlichter wrote:
> Think about two adjacent regular timer interrupts. Now consider the first one
> is handled very late (indeed even after the second interrupt already
> occoured). Then will see two "lost" ticks.
>
> Now directly the second timer interrupt handler is executed and, well it sees
> there has _nearly_ no time passed, so no "lost" ticks are reported.
Thomas,
In such a case, we should not increment jiffie during second interrupt
(mainline code increments jiffie always on a timer interrupt).
Also in such a case, it is probably not a good idea to drop offset_delay.
I think we should retain it - otherwise next tick will show up as zero ticks
lost?). There is another complication that the offset_tick recorded during
init_pmtmr may not be aligned on jiffy boundary. Ideally we want offset_tick
to be aligned as closely as possible to jiffy boundary. This is one of the
reason why I added setup_pit_timer in my patch during init_pmtmr.
After all this, I think the patch you sent out and what I had
sent are fundamentally same - they rely on some constant ticks per jiffy to be
seen for lost tick calculation. I have seen this works on some machines and
not on others. I am trying to come up with another way of calculating
lost ticks, which partially depends on some known PMTMR_TICKS_PER_JIFFY
_and_ also reads the PIT to find out how late we are in processing
the interrupt (refer delay_at_last_interrupt calculation in timer_tsc.c).
Note that if you are testing mainline kernel, probably it wont test
the lost tick calculation code as much as dynamic tick does, since
not many ticks may be lost in practice. This could be one of the reasons
why no one has probably complained about time drift bitterly in mainline!
I would be much happy to accept a solution which works with dynamic tick.
For this you will need to apply the set of patches I mailed out.
P.S : I think PMTMR_TICKS_PER_JIFFY has to be calculated differently,
since a tick is not exactly 1/HZ of a second (see definition
of LATCH and pm_ticks_per_jiffy in my patch).
--
Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560017
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |