Re: [ckrm-tech] Re: [RFC] Revised CKRM release

[Shailabh Nagar]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/