Hi!
i did not say latency sources, i said unpredictable
latency sources.
hardirq and softirq processing introduces near arbitrary latency at any
(irqs-enabled) point in the kernel. Hence they make all kernel code
unbound in essence - even the most trivial kernel code, sys_getpid().
...
[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....
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms