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    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site