Re: [patch] voluntary-preempt-2.6.8.1-P0

Ingo Molnar
2004-08-16T02:57:19Z

* Ingo Molnar <mingo@elte.hu> wrote:

> > I believe the constant-time behavior that I reported was an artifact
> > of ALSA xrun debugging. Now it seems like the latency produced *does*
> > correspond directly to the amount of memory being mlockall'ed. If
> > ./mlockall-test 1500 triggers an xrun at all it's ~0.2ms. 3000
> > triggers a ~1ms xrun, and 10000 a ~3 ms xrun.
>
> ah ...
>
> could this be some DMA starvation effect? Or is this xrun calculated
> from arrival of the audio interrupt (hence DMA completion) to the
> actual running of jackd?

i've attached mlock-test2.cc that should test this theory. The code
breaks up the mlock-ed region into 8 equal pieces and does mlock() on
them separately. It's basically a lock-break done in user-space. Does
this change the nature of xruns?

if it doesnt change the xruns then it shows that it's not the locking of
make_pages_present() that interacts with jackd, but it's what it does
that interacts with it (or with the audio driver).

assuming the DMA-starvation theory isnt excluded via mlock-test2.c:

prefaulting is quite memory-bandwidth-intense. It might even be that the
CPU, internally, deals with pagetable related memory fetches (and
writebacks) differently - e.g. gives it a higher priority on the bus.
Does your audio card have a maximum PCI latency setting already?

Ingo