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:1.062 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site