Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4]

[Ingo Molnar]

* Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> wrote:

> >poll() is quite complex and with a good number of locks in the path the
> >maximum latency increases accordingly.
> 
> how can poll(2) be more complex than read/write? if it is, it
> shouldn't be ;)

poll() is fundamentally more complex: it has to watch multiple channels,
while read()/write() has to watch only a single event channel. The fact
that read()/write() also has to do some actual IO makes little
difference to complexity, as poll() already has to do most of the
locking read()/write() has to do, to figure out that it _could_ do the
read()/write().

> >btw., couldnt jackd use a separate input and output thread (of identical
> >priority), to be purely read()/write() based? This method should also
> >solve the priority problems of poll(): the thread woken up later will do
> >the work later. (hence the _earlier_ interrupt source will be handled
> >first.) With poll() how do you tell which fd needs attention first, if
> >both are set?
> 
> we don't really care which one needs attention "first". [...]

well, order of processing can make a difference under a high event load.
Couldnt capture and playback interrupts be separate and differently
timed? I understand your previous points that the audio 'channels' are
highly coupled and cannot be considered separate 'event sources', but is
the same true for all the fds that jackd passes into poll()? Is it true
if multiple cards are used?

the scenario that could trigger problems is that if an event (or group
of events) triggers some processing in the highprio thread, and two more
events arrive, one at the beginning of the previous processing, one at
the end of it. Once the highprio thread calls poll() again, the timing
of the two events has been lost - and jackd could end up processing the
_later_ event.

while this should normally make no difference with low audio loads, i
can very much see this causing problem as the number of cards/events
increases. What is typically the longest amount of time the highprio
thread can spend 'processing' without being actively poll()-ing? I know
it is typically short, but what is roughly the longest amount of time?
(is it the 1.4 msecs displayed in one of Rui's earlier testresults?)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/