Subject: Re: Hard realtime scheduling
To: Jonathan Stone <email@example.com>
From: Oliver.Korpilla@gmx.de <Oliver.Korpilla@gmx.de>
Date: 04/12/2005 08:36:08
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
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,