You might take a look at the high-res-timers patch (see URL in
signature) where the timer interrupt is separated from the wall clock
computation. In that patch, do_timer() updates jiffies as needed and
then calls the wall clock update which can handle more than one jiffie
at a time.
One of the nasty problems, especially with machines such as yours (i.e.
lap tops), is the fact that TSC is NOT clocked at a fixed rate. It is
affected by throttling (reduced in 12.5% increments) and by power
management. The patch attempts to find a way thru these problems by
making the ACPI pm timer one of the options for keeping wall clock.
This timer is clocked at a constant rate regardless of power management,
indeed, it was created to address just these concerns. The down side is
that it accessed via an I/O instruction and thus adds overhead to the
tick processing and also to all attempts to read system time to a finer
level than the jiffie (most of which are internal, i.e. not from user
> One problem I see is that tsc_per_jiffie must be perfect or time will
> drift. I think it might work to not carry over the remainder from
> cycle to cycle under some conditions (no missed ticks) but I'd have
> to think about that the effects of timing jitter on this.
> Have attempts to address this problem been made before?
> What are the problems with incrementing jiffies by more than 1?
> What problems have I missed?
> What strategies might be employed to prevent degraded system
> performance since this code is in a criticle path?
> Have I competely missed something, the kernel already takes care of
> this and I have the problem all wrong?
> This problem also comes up with IDE access with dma off and I've
> seen reports of it when using frame buffers.
The IDE issue is correctly address by using DMA.
I think the real problem needs to be addressed, i.e. why does the SMI
(and/ or other code) keep the interrupt system off so long. Most
interrupts are completed in micro seconds, not milliseconds, lets fix
the real problem.
> Tyson D Sawyer iRobot Corporation
> Senior Systems Engineer Military Systems Division
> firstname.lastname@example.org Robots for the Real World
> 603-532-6900 ext 206 http://www.irobot.com
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to email@example.com
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-- George firstname.lastname@example.org High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/