lkml.org 
[lkml]   [2004]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [patch] voluntary-preempt-2.6.8.1-P0
    From
    Date
    On Sun, 2004-08-15 at 22:36, Ingo Molnar wrote:
    > * Lee Revell <rlrevell@joe-job.com> 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 mlockall-test.cc 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
    pseudo-patch?

    > 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.

    Lee

    -
    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:0.023 / U:59.724 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site