Re: Priority Inheritance Test (Real-Time Preemption)

[Esben Nielsen]

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 have attached the data. The files is named
 <kernel ver>-<depth>.<blocking tasks>.hist
Note especially 
 2.6.10-rc2-mm2-V0.7.30-10-3.20.hist
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.

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".

Esben


On Wed, 24 Nov 2004, Ingo Molnar wrote:

> 
> * Esben Nielsen <simlo@xxxxxxxxxx> wrote:
> 
> > Results (in short): 
> > -30-9 doesn't resolved nested locking well. The expected max locking time
> > in my test would be depth * 1ms - it is much higher just at a locking
> > depth at two.
> 
> could you check the -30-10 kernel i just uploaded? I fixed the PI bugs
> you reported (and found/fixed other ones as well).
> 
> 	Ingo
>

Attachment: 2.6.10-rc2-mm2-V0.7.30-10.tgz
Description: Binary data