Messages in this thread | | | Date | Thu, 25 Nov 2004 16:46:10 +0100 (MET) | From | Esben Nielsen <> | Subject | Re: Priority Inheritance Test (Real-Time Preemption) |
| |
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@phys.au.dk> 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 >
[unhandled content-type:application/octet-stream] | |