[lkml]   [2004]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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
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".


On Wed, 24 Nov 2004, Ingo Molnar wrote:

> * Esben Nielsen <> 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]
 \ /
  Last update: 2005-03-22 14:08    [W:0.064 / U:7.436 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site