[linux-audio-dev] another kernel patch?

[Jack O'Quin]

Paul Davis <paul at linuxaudiosystems.com> writes:

> the problem is not (just?) the time that the scheduler takes. its that
> its decision making process is opaque. when jackd runs, it knows for
> certain which pid/tid to run next. we don't want to cede control of
> that back to the kernel scheduler. 

No scheduler that I've ever seen, written, or heard of is going to
accept JACK's opinion on this subject as anything more than a strong
hint.  The scheduler is the main loop of the entire system, *it*
decides what to run next.

Suggestions are welcome, but JACK truly does *not* know for certain
what to run next.  An interrupt could intervene and make a
higher-priority realtime process ready.  Or, some other processor
could unlock such a thread.  At the very least, there probably needs
to be code in the return path from the system call like the old Unix
logic of testing `runrun' and calling sched().

> i think i've mentioned before that i'd like to do a paper on JACK
> someday for Usenix, with a focus on its capabilities for "user space
> cooperative real-time scheduling", or something like that.

Sounds good.
-- 
  joq