Messages in this thread | | | Date | Fri, 5 Aug 2005 13:38:24 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH 2.6.13-rc5-gitNOW] msleep() cannot be used from interrupt |
| |
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |