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.

-allen

-- 
                  Use NetBSD!  http://www.NetBSD.org/