[linux-audio-dev] another kernel patch?

[Roger Larsson]

On Sunday 30 November 2003 03.19, Jack O'Quin wrote:
> Roger Larsson <roger.larsson at norran.net> 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