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