* 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
-
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/