[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.322 / U:2.384 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site