Messages in this thread | | | Date | Fri, 13 Aug 2004 02:55:46 +0200 | From | Florian Schmidt <> | Subject | Re: [patch] voluntary-preempt-2.6.8-rc3-O5 |
| |
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/
- 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/
| |