Message-Id: <200410300106.i9U16fXJ010366@localhost.localdomain>
To: Ingo Molnar <mingo@elte.hu>
cc: Thomas Gleixner <tglx@linutronix.de>, LKML <linux-kernel@vger.kernel.org>,
       Bill Huey <bhuey@lnxw.com>, Adam Heath <doogie@debian.org>,
       Michal Schmidt <xschmi00@stud.feec.vutbr.cz>,
       Karsten Wiese <annabellesgarden@yahoo.de>,
       jackit-devel <jackit-devel@lists.sourceforge.net>
Subject: Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4] 
In-reply-to: Your message of "Fri, 29 Oct 2004 23:11:12 +0200."
             <20041029211112.GA9836@elte.hu> 
Date: Fri, 29 Oct 2004 21:06:41 -0400
From: Paul Davis <paul@linuxaudiosystems.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1298
Lines: 28

>but i'd also suggest to put in a counter into that branch so that this
>condition doesnt get lost. In fact the Maximum Process Cycle stat from
>Rui:
>
>>>   Maximum Delay . . . . . . . . .    6904       921       721    usecs
>>>   Maximum Process Cycle . . . . .    1449      1469      1590    usecs
>
>seems to suggest that there can be significant processing delays? (if
>Maximum Process Cycle is indeed the time spent from poll_ret to the next
>poll_enter.)

IIRC, Rui was running with -p128, which at 48000kHz is 2600usecs (and
longer at 44100kHz). If the maximum process cycle was on the order of
1500usecs, that leaves nearly 1ms until the next interrupt is
due. Unless jackd was held up between computing the process cycle time
and entering poll, it doesn't seem that the process cycle ever gets
close to the interrupt interval duration.

So I don't think that delays caused *during* jackd's processing cycle
are involved here. However, I agree that your suggestion to check for
this before computing max_delay is probably wise in general.

--p
-
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/