Messages in this thread | | | Date | Mon, 16 Aug 2004 04:58:46 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] voluntary-preempt-2.6.8.1-P0 |
| |
* 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/
| |