[lkml]   [2009]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFC for a new Scheduling policy/class in the Linux-kernel
    On Mon, 2009-07-13 at 15:45 -0600, Chris Friesen wrote:
    > > The only selling point for PIP has been the ability of a thread to
    > > suspend itself while holding a lock, such as to wait for
    > > completion of an I/O operation.
    > You're comparing a full-featured PI implementation with a stripped-down
    > PP (priority protection, aka priority ceiling) approach. In an
    > apples-to-apples comparison, the selling point for PI vs PP is that
    > under PIP the priority of the lock holder is automatically boosted only
    > if necessary, and only as high as necessary. On the other hand, PP
    > requires code analysis to properly set the ceilings for each individual
    > mutex.
    I think I agree with this.

    Moreover, talking about server/group based scheduling and considering
    BWI/PEP, which are natural extensions of PI, you get the very nice
    property of being independent from the actual knowledge of the blocking
    time(s): you can run your scheduling test only considering the bandwidth
    assigned to each component... And this is, at least for now and as far
    as I know, not possible if you go for preventivate-blocking approaches
    like P(C)P or SRP, and also for BROE or SIRAP I think.

    I mean, if you only want to be sure to isolate applications and/or
    components among themselves, without any knowledge of the blocking times
    and critical section access patterns of the task running inside such
    components, you can do it! Just pick up the bandwidths and see if they
    fit with a scheduling test unmodified by any --very difficult to find
    out, actually-- blocking term.
    I know, this does not cover all the possible situations, and that it is
    biased toward _soft_ real-time workloads, but I think it's a meaningful
    use-case, especially considering Linux...

    Anyway, it is more than possible that this belief is due to lack of
    knowledge of mine about some other already existing solution... If so,
    please, any pointer to it/them is more than welcome. :-)

    > > Regarding the notion of charging proxy execution to the budget of
    > > the client task, I have grave concerns. It is already hard enough
    > > to estimate the amount of budget that a real-time task requires,
    > > without this additional complication.
    > Agreed.
    Well, indeed, I agre with this as well... But it yields the, to me, very
    nice property described above (and in the other e-mail).

    However, I'm light year far from proposing it as the "solutions for all
    evils"! I know that, for instance, overhead and code twisting are severe
    issues. The all I hope is to be able and have the time to give it a try,
    and try to guess if it is worth. :-D

    Regards again,

    <<This happens because I choose it to happen!>> (Raistlin Majere)
    Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy) / /
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2009-07-14 13:19    [W:0.037 / U:39.592 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site