lkml.org 
[lkml]   [2004]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4]

    * Paul Davis <paul@linuxaudiosystems.com> 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:07    [W:4.404 / U:0.208 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site