[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.021 / U:0.588 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site