Re: [RFC] timer_interrupt: Avoid device timeouts by freezing time if system froze

From: David Mosberger-Tang <David.Mosberger_at_acm.org>
Date: 2005-09-10 09:18:03
I see your point about non-interrupt sources but the idea can be
generalized: rather than letting time catch up in a single huge jump,
do it gradually.  Say for every timer tick, you advance by one extra
tick.  I _think_ that could work well in practice.

  --david

On 9/9/05, Christoph Lameter <clameter@engr.sgi.com> wrote:
> On Fri, 9 Sep 2005, David Mosberger-Tang wrote:
> 
> > I also would be nervous about the proposed patch.
> 
> Yes, I am also a bit concerned but there seems to be no other
> good solution.
> 
> > I'm wondering: could the problem be avoided perhaps by running all
> > other pending (lower-priority) interrupts first when you detect a
> > large jump in elapsed time?  In other words, when you detect a jump
> > from time T1 to T2 with (T2-T1) greater than some threshold, you make
> > sure you run all pending interrupts while still at time T1 and only
> > after that is done you let time catch up to T2.
> 
> I think we are not talking about hardware interupts. Those can happen
> anytime and given the system was frozen for an extended time period
> likely have already completed before the timer interrupt happens for
> the first time after the system begins to unfreeze.
> 
> I think the main issue are drivers events. These are dependent on jiffies
> (which may be checked by drivers in a varity of ways) or are timer events
> (which also may expect jiffies to have a certain value).
> 


-- 
Mosberger Consulting LLC, voice/fax: 510-744-9372,
http://www.mosberger-consulting.com/
35706 Runckel Lane, Fremont, CA 94536
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Sat Sep 10 09:18:42 2005

This archive was generated by hypermail 2.1.8 : 2005-09-10 09:18:49 EST