lkml.org 
[lkml]   [2004]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:4.204 / U:0.152 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site