lkml.org 
[lkml]   [2009]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: RFC for a new Scheduling policy/class in the Linux-kernel
    Date
    > I think you can extend PIP to include things like bandwidth  
    > inheritance
    > too. Instead of simply propagating the priority through the waitqueue
    > hierarchy, you can pass the actual task around, and having this
    > task you
    > can indeed consume its bandwidth etc..

    I think I understand what you are suggesting by "pass the actual task
    around". If not, this message might seem out of place.

    Consider this locking chain/graph:

    A-->L1-->B-->L2-->C
    D-->L3-->E-->L2

    The way I understand what you are suggesting is that tasks A,B,D,E
    (or some representation of them) can be passed around such that when
    C executes it consumes some resource associated with the the tasks it
    is blocking (A,B,D,E). Obviously which tasks and what quantities are
    dependent on scheduling semantics and configuration.

    The biggest implementation hurdle we have encountered is that as
    tasks are passed forward along a locking chain knowledge about the
    structure of the locking chain is lost. For example, as C releases
    L2, C must be able to distinguish between A and D as having been
    passed to C's location through B or E, respectively.

    Keeping a representation of the locking chain as a full graph is the
    solution we have used. Another solution is to allow A and D to re-
    block and walk the locking chain again, but obviously some thundering-
    hurd issues arise.

    noah






    \
     
     \ /
      Last update: 2009-07-13 20:23    [W:0.036 / U:0.012 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site