Subject: Re: Hard realtime scheduling
From: Jonathan Stone <email@example.com>
Date: 04/04/2005 13:06:32
In message <Pine.OSF.firstname.lastname@example.org>,
>On Mon, 4 Apr 2005, SODA Noriyuki wrote:
>> >>>>> On Mon, 4 Apr 2005 12:02:07 +0200 (CEST),
>> Hubert Feyrer <email@example.com> said:
>> > I don't know about any details in NetBSD, but the way to go is probably to
>> > make the kernel preemptive as first step. This will also (hugely) benefit
>> > SMP performance (i.e. no more biglock).
I think this is exactly backwards. The important part is to remove the
big-lock: -/. That will immediately benefit SMP performance, and also
makes pre-emption significantly more feasible.
>> mm, first step.
>> I think this is really hard step, although it's worth consindering.
>> Adding realtime (fixed priority) scheduling class to our scheduler is
>> worth doing, and far easier than preemptive kernel.
>As I stated earlier, realtime scheduling, especially not requiring root
>access, will be a boon to good quality audio support. I'm hoping that
>we'll have something that can be used by JACK. I never got any comments
>on this at the time. Can I get some now?
Point of information: We can add the userspace API hooks required for
a real-time scheduler relatively easily. But until the kernel is made
pre-emptive, so that the "real-time scheduler" can pre-empt kernel
activity as well as pre-empting other userspace tasks, such real-time
hooks don't seem worth much.
An illustrative point: Solaris. if memory serves, when Solaris added
real-time scheduler hooks, one of the changes made was going through
the kernel source, manually identifying all "long-running" codepaths.
Checks were inserted into each such path, to check for nearly-overdue
real-time tasks, and go switch to the real-time task if required.
Is there something I'm missing here? For example, maybe you can
guarantee that on your machine, your "real-time app" is is only
contending with other userspace tasks, not with the kernel, or
with I/O on behalf of other tasks, usw.
But that doesn't sound very "real-time" to me