29 Nov
2003
29 Nov
'03
8:57 p.m.
On Saturday 29 November 2003 21.55, Paul Davis wrote:
Let see - what you want is this:
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
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.
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".