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....
Pavel
Ordinarily, yes. However, if it's a high-priority RT task that does
the getpid(), whose priority is higher than that of the RT tasks,
you'll get at most one hardirq stub per active IRQ number; after
that, the IRQs will be masked until their threads get a chance to be
scheduled.
But will not even num_IRQs*time_per_stub be so high that any analysis
is impractical?
...
...
Hmm, that high-priority hask only has to eat num_IRQs*time_per_stub
once, so perhaps its okay.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!