[lkml]   [2004]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] voluntary-preempt-
    On Sun, 2004-08-15 at 22:36, Ingo Molnar wrote:
    > * Lee Revell <> wrote:
    > > There are a number of samples above 700us. I am working with a period
    > > time of 666 usecs, and since there are 2 periods per buffer, we would
    > > have to hit two > 666 usec latencies in a row for an xrun - it appears
    > > that there are many individual latencies above 666, certainly more
    > > than there are xruns. So, maybe the mlockall issue is not a result of
    > > triggering a single large latency, but of increasing the frequency of
    > > these higher latencies so that we are more likely to hit 2 in a row.
    > hm, it seems the mlockall() issue is too deterministic for it to be a
    > statistical-only phenomenon. Also, isnt that xrun on the order of 15
    > msecs? That's way too big too.

    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.

    > > IIRC ksoftirqd will defer more work under load, and ksoftirqd is one
    > > of the more common offenders to hit the extract_entropy latency.
    > > Maybe mlockall causes more softirqs to be deferred, thus increaing the
    > > change that we will have to do more than 666 usecs worth of work on 2
    > > successive wakeups.
    > there should be no relation between softirqs and mlockall().
    > this is truly a mind-boggling latency. mlockall() is fully preemptible.
    > All it does is to pre-fault the whole range of pages that a process has.
    > could you try another thing: modify to use mlock() on
    > the freshly allocated anonymous pages? Does this produce the same
    > latencies? mlockall() prefaults _all_ pages the process currently has.
    > Maybe mlockall() touches some page that is mapped both by jackd and
    > mlockall-test and thus somehow interacts with jackd's scheduling.

    I don't know C++, Florian wrote this program. Can you provide a

    > the anonymous pages themselves can have no IPC-alike connection to any
    > page jackd owns. It is unlikely for that to be any connection between
    > jackd and mlockall-test - other than both map glibc. To further exclude
    > any possibility of resource sharing between jackd and mlockall-test,
    > could you compile the later with -static?

    Sure, I will try this.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:05    [W:0.023 / U:1.224 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site