* Pavel Machek <[EMAIL PROTECTED]> wrote:
> ...
> > [the only remaining source of 'latency uncertainty' is the small
> > asynchronous hardirq stub that would still remain. This has an effect
> > that can be compared to e.g. cache effects and it cannot become unbound
> > unless the CPU is bombarded with a very high number of interrupts.]
>
> Well, I do not follow you I guess.
>
> With large-enough number of hardirqs you do no progress at all.
>
> Even if only "sane" number of irqs, if they all decide to hit within
> one getpid(), this getpid is going to take quite long....
yes, all of this assumes some _minimal_ sanity of the hardware
environment. We do detect interrupt storms and turn those IRQ sources
off, but there's no (sane) way to avoid interrupt storms from
driver-handled IRQ sources.
Ingo
