lkml.org 
[lkml]   [2004]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ckrm-tech] Re: [RFC] Revised CKRM release
    Marcelo Tosatti wrote:
    > On Thu, Apr 29, 2004 at 04:25:21AM -0400, Shailabh Nagar wrote:
    >
    >>The Class-based Resource Management project is happy to release the
    >>first bits of a working prototype following a major revision of its
    >>interface and internal organization.
    >>
    >>The basic concepts and motivation of CKRM remain the same as described
    >>in the overview at http://ckrm.sf.net. Privileged users can define
    >>classes consisting of groups of kernel objects (currently tasks and
    >>sockets) and specify shares for these classes. Resource controllers,
    >>which are independent of each other, can regulate and monitor the
    >>resources consumed by classes e.g the CPU controller will control the
    >>CPU time received by a class etc. Optional classification engines,
    >>implemented as kernel modules, can assist in the automatic
    >>classification of the kernel objects (tasks/sockets currently) into
    >>classes.
    >
    >
    > Cool!
    >
    >
    >>New in this release are the following:
    >>
    >>rbce.ckrm-E12:
    >>
    >>Two classification engines (CE) to assist in automatic classification
    >>of tasks and sockets. The first one, rbce, implements a rule-based
    >>classification engine which is generic enough for most users. The
    >>second, called crbce, is a variant of rbce which additionally provides
    >>information on significant kernel events (where a task/socket could
    >>get reclassified) to userspace as well as reports per-process wait
    >>times for cpu, memory, io etc. Such information can be used by user
    >>level tools to reclassify tasks to new classes, change class shares
    >>etc.
    >
    >
    > It sounds to me the classification engine can be moved to userspace?
    >
    > Such "classification" sounds a better suited to be done there.

    I suppose it could. However, one of our design objectives was to
    support multi-threaded server apps where each thread (task) changes
    its class fairly rapidly (say every time it starts doing work on
    behalf of a more/less important transaction). Doing a transition to
    userspace and back may be too costly for such a scenario.

    There might also be some concerns with keeping the reclassify
    operation atomic wrt deletion of the target class...but we haven't
    thought this through for userspace classification.



    >
    > Note: I haven't read the code yet.
    >

    Why just read when you can test as well :-) We just released a testing
    tarball at http://ckrm.sf.net.. any inputs, bugs will be most welcome !



    Looking forward to more inputs,
    -- Shailabh
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:02    [W:5.437 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site