Subject: Re: Hard realtime scheduling
To: Oliver.Korpilla@gmx.de <Oliver.Korpilla@gmx.de>
From: Allen Briggs <firstname.lastname@example.org>
Date: 04/12/2005 11:16:20
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.
Use NetBSD! http://www.NetBSD.org/