From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264113AbUGMH61 (ORCPT ); Tue, 13 Jul 2004 03:58:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264479AbUGMH61 (ORCPT ); Tue, 13 Jul 2004 03:58:27 -0400 Received: from cantor.suse.de ([195.135.220.2]:56041 "EHLO Cantor.suse.de") by vger.kernel.org with ESMTP id S264373AbUGMH6N (ORCPT ); Tue, 13 Jul 2004 03:58:13 -0400 Date: Tue, 13 Jul 2004 09:58:10 +0200 Message-ID: From: Takashi Iwai To: Paul Davis Cc: Andrew Morton , Lee Revell , linux-audio-dev@music.columbia.edu, mingo@elte.hu, arjanv@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch In-Reply-To: <200407130001.i6D01pkJ003489@localhost.localdomain> References: <20040712163141.31ef1ad6.akpm@osdl.org> <200407130001.i6D01pkJ003489@localhost.localdomain> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 MULE XEmacs/21.4 (patch 15) (Security Through Obscurity) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At Mon, 12 Jul 2004 20:01:51 -0400, Paul Davis wrote: > > >OK, thanks. The problem areas there are the timer-based route cache > >flushing and reiserfs. > > > >We can probably fix the route caceh thing by rescheduling the timer after > >having handled 1000 routes or whatever, although I do wonder if this is a > >thing we really need to bother about - what else was that machine up to? > > i have one concern about this that i talked to takashi about when we > were in bordeaux. it seems to me that the ALSA xrun debug stuff is > measuring things when the interrupt handler for the ALSA device > executes and detects an xrun. if the handler itself was delayed, then > the stack trace for its execution doesn't or might not show what > caused the delay. this means, perhaps, that we need to be rather > careful interpreting these traces. Well, it can catch up too long critical sections in most cases, although it cannot measure the latency to wake up the audio thread. So, the detection can't be 100% guaranteed. Takashi