[linux-audio-dev] another kernel patch?

[Roger Larsson]

On Saturday 29 November 2003 21.55, Paul Davis wrote:
> >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.
>
> i'm not trying to subvert the general operation of the scheduler. it
> will still intervene when it needs/wants to.

Let see - what you want is this:
>
> what i want to stop is this: jackd is about running the process cycle,
> and wants to hand control to the next client. it writes to a FIFO to
> wakeup the next client, 

If next client is a RT process (SCHED_FIFO/RR) then it WILL be selected
unless there is another RT process with higher priority, and lower than jackd
otherwice it would have been running in the first place.


> and goes to sleep waiting for the "baton-passing" to wake it up again.

Jackd waits...

> however, for some bizarre reason, the scheduler does not in fact run the
> next client, but does something else instead.

If this ever happens (and something else is not within in the priority range
new process ... jackd) then it is a scheduler BUG - and should be fixed!

Cases where RT processes ends up flushing page cache to disk should
be investigated and fixed. If any...

>
> put another way, i want JACK-the-system to keep running smoothly, even
> though this includes crossing process boundaries. i don't want the
> handoff of control that is implicit in running the process cycle to
> return control to the scheduler "unnaturally".
>

But the current scheme can do more. Suppose you are running on a SMP
machine (Chip level SMP processors are getting common - there is even a
Xilinx FPGA - Virtex Pro with four PowerPCs [Not G5 but anyway...]!)

Suppose that in this situation you have made data available for several
processes - how can you start them all with your suggested interface?
(You might want to start them all and let the scheduler figure out what
to do - hyperthreading is nice when using the same data)

With the current scheme (OK, I am not quite up to date)
you could write to the FIFOs of all ready processes before starting to
wait on the baton. [giving the sub processes different priority levels
will order them in case you have less processors than CPUs]

> >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().
>
> obviously, all these would remain in place and we would be doing
> nothing subvert them. all we are doing is avoiding a schedule() caused
> by jackd blocking-on-read and the next client being marked
> runnable. both jackd and the next client should be considered "part of
> the same system".

To get this you should run the clients with higher priority than jackd!
Then they would be started and run before returning from the FIFO
write! :-)


client A requests data from FIFO
	kernel lets A waits on FIFO
						jackd writes data to FIFO
							kernel puts data on FIFO
							kernel wakes up waiters

--- client A has higher prio than jackd, it will preempt jackd while
--- jackd is still in the kernel.

client A wakes up
processes
returns baton
waits for more data on FIFO
	kernel finds next task to run
							and finds jackd (still on run queue)
							kernel returns
						jackd checks for baton - got it.
						jackd determines what client to run next.

Maybe jack should handle the priorities for jack clients - priorities is a
relative issue anyway... Then jackd could use this scheme when there
is only one client to run - and the lower priority clients when there are 
several.

/RogerL

-- 
Roger Larsson
Skellefteå
Sweden