Re: [patch] voluntary-preempt-2.6.8-rc3-O5

[Florian Schmidt <mista.tapas@gmx.net>]

On Thu, 12 Aug 2004 20:27:57 -0400
Lee Revell <rlrevell@joe-job.com> wrote:

> On Thu, 2004-08-12 at 20:04, Lee Revell wrote:
> 
> > So, it seems that if a SCHED_FIFO process opens a PCM device using
> > mmap, then mlockall's the memory, then another process mlockall's
> > memory, the result is an xrun 100% of the time.
> > 
> 
> I have found that around 1400 KB is a magic number on my system, this
> triggers the preempt violation/xrun about 50% of the time.  1300 never
> triggers it, 1500 always triggers it.
> 
> Also the amount of memory being mlockall'ed does not affect the length
> of the preemption violation - if we hit it at all, there's a 10ms
> latency, whether we lock 1400KB or 100MB.
> 
> Hopefully O6 will give enough info to track this down.

Hi, 

i think that the mlockall and client/jackd startup xruns often do not
seem to correspond to a critical timing report.. Try the following: turn
off xrun_debug but leave the preempt-timing stuff on. On my system, the
mlockall_test provokes an xrun in jackd's output but i do not get a
preempt-timing report (thresh = 500). 

OTOH when the xrun_debug is on, the xrun_debug report actually seems to
trigger the preempt-timing report.

I think many of the jackd xruns are really jacks business. But maybe i
misinterpret the symptom.

BTW: on my system with 2*64 frames the magic mlockall number seems to be
around 15megs.. mlockall'ing only 10megs is very unlikely to trigger an
xrun in jackd  And even mlockall'ing 100 megs, while always producing an
xrun in jackd, doesn't show a corresponding preempt timing report either
[with preempt_thresh = 500] as long as the xrun_debug is off. 

Flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/