lkml.org 
[lkml]   [2004]   [Nov]   [1]   [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:

> >
> >* Florian Schmidt <mista.tapas@gmx.net> wrote:
> >
> >> new max. jitter: 4.3% (41 usec)
> >> new max. jitter: 4.9% (47 usec)
> >
> >a couple of conceptual questions: why does rtc_wakeup poll() on
> >/dev/rtc? Shouldnt a read() be enough?
>
> i suggested to florian that it should model jackd's behaviour as
> closely as possible. because jackd requires duplex operation, using
> just read/write doesn't work.

ok - but i think there should at least be an option to turn the
poll()-ing off. To showcase the best-possible wakeup latency offered by
the kernel :-)

poll() is quite complex and with a good number of locks in the path the
maximum latency increases accordingly.

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?

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:1.031 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site