Allen Briggs wrote:

>On Tue, Apr 12, 2005 at 08:36:08AM +0200, Oliver.Korpilla@gmx.de wrote:
>  
>
>>This actually improves SMP and preemption, and enables the user to much 
>>more easily determine the latency, because he needs no longer to check 
>>all system calls (208, if I remember - 207 + clone()) for longest path 
>>under lock, but only those that tap into the same resources: Resetting 
>>hard drive parameters (which has a _huge_ path under lock) can no longer 
>>interfere with locking in the UDP/IP stack, e.g. The latency is much 
>>easier to test out and/or to analyze.
>>    
>>
>
>Don't you also have to measure the interrupt paths?  Is Linux still
>using sti/cli, essentially, for masking interrupts?  NetBSD, when
>allowed by the hardware, often uses an interrupt priority scheme
>where higher-priority interrupts can interrupt lower-priority
>interrupts during processing.  I would think that this would tend
>to make analysis a bit more difficult.
>
>Hmm...  Unless all you care about is the highest-priority interrupt--
>in which case you would just have to measure the code paths where
>interrupts are disabled and any paths that hold resources you need.
>  
>
I guess in this scheme interrupts where of equal importance, except the 
Non-Maskable-Interrupt.

But due to deferred routines (called tasklets in Linux) all kernel 
interrupt routines tended to be extremely short and were largely 
subsumed as acceptable jitter in comparison to all other factors 
involved in the latency determination. After the interrupt service 
routine entered the tasklet into the appropriate data structure, it is a 
case of normal execution again, because the tasklet can be preempted, as 
it is "only" a kernel-level thread.

Of course this scheme is suboptimal, because without clearly assigned 
priorities for interrupts non-critical events could possibly block a 
much more mission-critical one...

With kind regards,
Oliver Korpilla