On Sunday 30 November 2003 03.19, Jack O'Quin wrote: > Roger Larsson <[EMAIL PROTECTED]> writes: > > 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. > > I wish this were the true. But, I strongly suspect that it is not. > > > > 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! > > That's right. But, Paul and I have been working closely with this and > don't have much faith in the correctness of the 2.4 scheduler.
Have you told kernel developers about this? This can be rather critical in embedded systems. > Like all non-trivial software components it has bugs, and getting them > fixed is difficult, if not impossible. But the scheduler is VERY simple when you are using RT (SCHED_FIFO/RR). It only selects the one with highest priority. So unless your thread falls off the run queue - critical. Does not timely get on the run queue after wake up - critical. Gets stuck somewhere else - program bug? But it could also be jackd the gets stuck doing something else... (this is the reason why I am not comfortable with the printfs in my rt_monitor - they use the console and it is bad...) Anyway try to describe your problems in linux-kernel (cc me) > > > 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] > > The current JACK implementation is completely single-threaded > regardless of how many real or virtual processors your system > possesses. > > But, for some (relatively complex) graphs a multithread schedule would > be possible and desirable. So, theoretically your point is valid. > > > 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. > > What problem does this solve? It will better match what you think you do. When jackd writes in the FIFO - expect client to start. Jackd waits for baton - wait for client to finish. But with jackd as highest priority: Jackd writes to FIFO - nothing will happen for client. Jackd _waits_ for baton - now client start, processes, finishes. You could try a low priority jackd (still RT) in this way to see if things behave better. Next week I will read some jack and kernel code if you can try to explain what happens. /RogerL -- Roger Larsson Skellefteċ Sweden