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

[Ingo Molnar <mingo@elte.hu>]

* 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