[lkml]   [2004]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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 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
    > Cool!
    >>New in this release are the following:
    >>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
    > 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 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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:02    [W:0.024 / U:8.984 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site