Jonathan Stone wrote:
> OTOH, if we're talking about uniprocessor kernels on desktops/laptops
> running sound and GUIs, (which was how I read the original request??),
> then SCHED_LOCK() is just splsched(): arguably even less friendly to
> pre-emption.

I don't think so - if you refer to my question as "the original 
request". I was thinking of guaranteed, bounded latency as needed for 
hard realtime systems (where more often than not uniprocessors are used).

Last summer I did a project with a preemptible Linux kernel with 
resource-bound locking (a lock held on a different resource will not 
block preemption if you don't want that lock, too), which is actually 
even finer-grained locking.

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.

This was actually a fix to the Linux kernel preemption patch: The 
preemption patch as in plain vanilla 2.6.x exposed the property to 
decrease the average latency (which is in the usec magnitude) but to 
fail at decreasing the worst case latency (which is in the several 100s 
of msecs - clearly unacceptable).

The catch with preemption was that it was only enabled when not under 
lock, to avoid data corruption. It therefore lowered the average latency 
because of fine-grained locking - a lot of code was now beyond lock, 
especially when you use the low-latency-patches (which break down locks, 
loops under lock, and insert preemption points).

But since the longest path under lock depend on all code paths of all 
programs involved and all processes "fight" for the locks within the 
system calls, worst case latency could neither be characterized as 
deterministic nor easily determinable. Altering the behaviour to be 
resource-specific improved things a lot. But you can only do that, if 
you have already a well-tested fine-grained SMP locking.

Just my 2 cents. :)

With kind regards,
Oliver Korpilla