In message <Pine.OSF.4.58.0504041118060.28083@pegasus.cs.csubak.edu>,
Dave writes:

>On Mon, 4 Apr 2005, SODA Noriyuki wrote:
>
>> >>>>> On Mon, 4 Apr 2005 12:02:07 +0200 (CEST),
>> 	Hubert Feyrer <hubert@feyrer.de> 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