Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263174AbUJ2JP5 (ORCPT ); Fri, 29 Oct 2004 05:15:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263173AbUJ2JP5 (ORCPT ); Fri, 29 Oct 2004 05:15:57 -0400 Received: from mx1.elte.hu ([157.181.1.137]:9655 "EHLO mx1.elte.hu") by vger.kernel.org with ESMTP id S263174AbUJ2JMD (ORCPT ); Fri, 29 Oct 2004 05:12:03 -0400 Date: Fri, 29 Oct 2004 11:09:57 +0200 From: Ingo Molnar To: Thomas Gleixner Cc: Paul Davis , LKML , Lee Revell , mark_h_johnson@raytheon.com, Bill Huey , Adam Heath , Florian Schmidt , Michal Schmidt , Fernando Pablo Lopez-Lezcano , Karsten Wiese , jackit-devel , Rui Nuno Capela Subject: Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4] Message-ID: <20041029090957.GA1460@elte.hu> References: <1099008264.4199.4.camel@krustophenia.net> <200410290057.i9T0v5I8011561@localhost.localdomain> <20041029080247.GC30400@elte.hu> <1099038063.22387.534.camel@thomas> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1099038063.22387.534.camel@thomas> User-Agent: Mutt/1.4.1i X-ELTE-SpamVersion: MailScanner 4.31.6-itk1 (ELTE 1.2) SpamAssassin 2.63 ClamAV 0.73 X-ELTE-VirusStatus: clean X-ELTE-SpamCheck: no X-ELTE-SpamCheck-Details: score=-4.9, required 5.9, autolearn=not spam, BAYES_00 -4.90 X-ELTE-SpamLevel: X-ELTE-SpamScore: -4 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1112 Lines: 25 * Thomas Gleixner wrote: > The sound subsystem uses a lot of sleep_on() variants. We know that > they are racy. Might this be related ? i doubt it is related - sleep_on() is mostly racy on SMP and Rui is doing UP tests. Also, for a sleep_on() race to occur you'd have to race with the wakeup - but in the Jackd case that is highly unlikely because it sleeps well before the next interrupt is due. So while a sleep_on() race could in theory make _existing_ latencies worse, it cannot by itself introduce the first latency. but now it should be possible to prove that Jackd itself doesnt introduce latencies, via the userspace-atomicity mode feature in -V0.5.5 :-) If that proves that the latencies dont occur in Jackd (and if it's not another, even higher prio thread that causes the delay) then we can pass the ball back to the kernel. Ingo - 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/