Messages in this thread | | | Date | Fri, 28 Jan 2005 09:47:25 +0100 | From | Ingo Molnar <> | Subject | Re: High resolution timers and BH processing on -RT |
| |
* Thomas Gleixner <tglx@linutronix.de> wrote:
> > or is it that we have a 'group' of normal timers expiring, which, if > > they happen to occur _just_ prior a HRT event will generate a larger > > delay? > > Yep. The timers expire at random times. So it's likely to have short > sequences of timer interrupts going off. This needs reprogramming of > the PIT and processing of the expired timers.
i dont really like the static splitup of 'normal' vs. 'HRT' timers - there might in fact be separate priority requirements between HRT timers too.
i think one possible solution would be to introduce some notion of 'timer priority', and to expire each timer priority level in a separate timer expiry thread. Priority 0 (lowest) would be expired in ksoftirqd, and there would be 3 separate threads for say priorities 1-3. Or something like this. Potentially exposed to user-space as well, via new APIs. Hm?
To push this even further: in theory timers could inherit the priority of the task that starts them, and they would be expired in that priority order - but this probably needs a pretty clever (and most likely complex) data-structure ...
Ingo - 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/
| |