[lkml]   [2004]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Minutes from 5/19 CKRM/PAGG discussion
    Rik van Riel wrote:

    >On Mon, 24 May 2004, Hanna Linder wrote:
    >>Minutes from LSE call on CKRM and PAGG on May 19, 2004.
    >Thanks for organising this call, Hanna!
    Thanks 2.. sorry I couldn't make it ...

    >> CSA/PAGG look at CKRM
    >> CKRM look at PAGG
    >I really hope the projects will be able to agree on one
    >framework. As long as there are multiple competing
    >frameworks the chance of any of them being merged into
    >the upstream kernel is exceedingly low...
    Agreed, so let's get the ball rolling.

    We (CKRM team) will look at PAGG (again) ... Actually we did
    last year and basically assumed due to the inactivity that
    PAGG was not actively persued anymore.

    I believe at our end we will come to the conclusion that CKRM can serve
    as the base for CSA, as PAGG seems to be lowest level layer of
    this management silo. The level CSA would hook to is that of
    the CKRM event hooking which is part of the CKRM core.

    One important input the PAGG team could give is some real
    examples where actually multiple associations to different groups
    is required and help us appreciate that position and let us
    see how this would/could be done in CKRM.

    From our point of view we don't see this requirement. In contrast
    we use the modified rbce (CRBCE) to push the "interesting" kernel events
    to userspace where any kind of accounting aggregation can take place.
    Yet, we believe the integrated resource scheduling (e.g. cpu) will
    always happen at the dominant class - object association in the kernel.

    Another point that has not been made is that CKRM's philosophy
    is to manage any kind of objects wrt to some class type.
    By definition, PAGG is a Process Aggregation, which is a subset
    of what CKRM needs namely (obj->class) associations.

    In our hooking scheme we therefore provide the ability to attach
    to so called kernel events a callback function. Any kernel code
    can attach a callback function. This is part of our core.

    Any classtype (not part of the core) can register a callback at
    any of those events, so typically only limited
    events are "hooked" for a particular type. Regardless, we have
    function stacking, rather then object stacking.

    PAGG by itself manages the proper association of a (or several)
    "transparent" group object with the task. The functionality
    hidden behind the group object
    still needs to be implemented by the group object itself.

    In CKRM this is similar, yet, the class object is associated with
    a particular class type. All interactions with the user component
    and classification engine are architected by the higher layers of CKRM,
    in that classes have automatic representation in RCFS and RBCE if
    those are loaded.

    So here are some of the stickling points, we need to work on ...

    (a) how can PAGG be made general enough so we can provide generic
    KernelObject <-> ClassObject associations .. not just tasks groups.

    (b) Can CSA use the extended rbce (CRBCE) instead of PAGG to
    do its accounting ?

    -- Hubertus Franke

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:03    [W:0.042 / U:4.236 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site