Re: [PATCH 2.6.13-rc5-gitNOW] msleep() cannot be used frominterrupt

[Andrew Morton]

Venkatesh Pallipadi <venkatesh.pallipadi@xxxxxxxxx> wrote:
>
> On Fri, Aug 05, 2005 at 11:53:29AM -0700, Andrew Morton wrote:
> > 
> > That's all pretty sad stuff.  I guess for now we can go back to the busy
> > loop.  Longer-term it would be nice if we could tune up the HPET driver in
> > some manner so we can avoid this busy-wait-in-interrupt.
> > 
> > I'm not sure who the HPET maintainer/expert is nowadays.  Robert Picco did
> > the original work but I haven't seen Robert around for a long time?
> 
> Actually there are two parts in HPET. 
> 1) Using HPET for kernel timer and RTC emulation
> 2) HPET driver to export timers to user(/dev/hpet) and kernel drivers
> 
> We did the part (1) for i386 and I think Andi/Vojtech did (1) for x86_64. And 
> Robert Picco did (2).

OK, thanks.

> So, using rtc_get_rtc_time() in an interrupt handler will be my code. In this
> part we try to emulate RTC interrupt using HPET and we have to read the current
> RTC time in the interrupt handler. I can't think of any way of not doing
> rtc_get_rtc_time here.
>
> I think we should have two versions of rtc_get_rtc_time. One which does msleep,
> that can be called from process context (in drivers/char/rtc.c) and one that
> can be called from interrupt context (i386 and x86_64 hpet time routines). Or 
> same routine behaving differently depending on where it is called from.

Yes, we could do that.  But when one is chasing "worst-case latency", we
need to address the worst-case machine, as well as the worst-case
codepath...

> And for the hpet rtc emulation routines it should be OK even if the time is 
> slightly off and not exact. So, probably we should be able to force read
> rtc even when update is in progress. That way we can avoid the busy loop.
> Unless RTC returns grossly wrong time values while UIP flag is set. I need to
> look at RTC specs to verify that.

Yup, no hurry.  If we can improve that codepath sometime it'd be nice, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/