Date: Thu, 25 Nov 2004 17:58:29 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Esben Nielsen <simlo@phys.au.dk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Priority Inheritance Test (Real-Time Preemption)
Message-ID: <20041125165829.GA24121@elte.hu>
References: <20041124101854.GA686@elte.hu> <Pine.OSF.4.05.10411251159520.12827-101000@da410.ifa.au.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.OSF.4.05.10411251159520.12827-101000@da410.ifa.au.dk>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2055
Lines: 45


* Esben Nielsen <simlo@phys.au.dk> wrote:

> I finally got time to run the test on 2.6.10-rc2-mm2-V0.7.30-10.
> Conclusion: The bound on the locking time seems not to be bounded by
> depth*1ms as predicted: The more blocking tasks there is the higher
> the bound is.  There _is_ some kind of bound in that I don't see wild
> locking times. The distributions stops nicely at N *1ms N in is higher
> than depth.

i've fixed a couple of minor, priority-related bugs in kernels post
-30-10, the latest being -31-7 - there's some chance that one of them
might fix this final anomaly.

> which is depth 3 and 20 blocking tasks. There is a clean upper bound
> of 7ms (7.1 to be exact) but where does the 7 come from??? A formula
> like N=2*depth+1 might fit the results.

there's one thing i noticed, now that the blocker device is in the
kernel, you have to be really careful to compile the userspace loop()
code via the same gcc flags as the kernel did. Minor differences in
compiler options can skew the timing calibration.

but any such bug should at most cause a linear deviation via a constant
factor multiplication, while the data shows a systematic nonlinear
transformation.

> If we understand what is going on this might end up being "good
> enough" in the sense it is deterministic. The end result doesn't have
> to be the best case formula. But the maximum locking time have to
> independent of the number of lower priority tasks banging on the
> protected region as that is something uncontrolable. We have to be
> able to predict a bound based solely on the depth before we can say it
> is "good enough".

yeah, i agree that this has to be further investigated. What type of box
did you test it on - UP or SMP? (SMP scheduling of RT tasks only got
fully correct in the very latest -31-7 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/