lkml.org 
[lkml]   [2004]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Revised CKRM release
Hi Christoph,


Christoph Hellwig wrote:
>>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.
>
>
> I'd still love to see practical problems this thing is solving.

We'd outlined three scenarios in our OLS'03 presentation
http://ckrm.sourceforge.net/documentation/ckrm-ols03-presentation.pdf

a) application server serving multiple requests from customers of
varying importance. The app server dynamically spawns processes to
handle each customers request. We need to group all the processes that
are currently serving a low-importance "bronze" customer and ensure
they don't take resources away from the group serving a "gold" customer.
Important criteria: don't assume the processes spawned always serve
the same customer (or customer type) ie. retain the flexibility for
them being able to have a "gold" priority for some time and then
revert to a "bronze" status.
--> needs processes to be classified into groups and regulated
based on some app-specific rules which cannot be predicted by the
kernel in advance.


b) Desktop user doing a combination of activites with different
priorities (for him/her), say:
compiling (lower) + listening to music (higher)
--> needs music player to be given a higher share of all
resources (cpu, mem, io) than the compile.
disk backup (very low) + checking email (higher)
--> needs io requests for email to be given a higher "share"

c) Multiple User-mode Linux instances running on a box (for virtual
hosting). Each uml instance, serving a different type of consumer (say
paying vs. nonpaying) needs a different level of service.
--> need to define groups of processes which are spawned by the
same uml instance

Besides, we have

d) department servers: multiple users logging in. Limit each
user/login to a fixed share of cpu/mem/io.
--> need to define groups of processes with same uid/gid or sharing
the same tty....

e) monitor how much load is being seen by a related group of
applications on a Linux box (perhaps to decide whether they're better
hosted on another box).
--> needs to group processes by application group even when the
command names are arbitrary), should accomodate short-lived apps etc.

f) tcp connection requests for an http server are coming from sites
with varying importance to the httpd owner. Serve some sites
preferentially.
--> needs incoming tcp connections to be accepted at differential
rates for groups of listening sockets formed using source ip/port.



> It's a few thousand lines of code, not written to linux style guidelines,

Guilty as charged :-( We will work to fix that until all are happy :-)

> sometimes particularly obsfucated with callbacks all over the place.

Not guilty ! Callbacks all over the place keep the various components
independent - the resource controllers (which are/will be patches over
the kernel schedulers), the classification engine module (which
assists in automatic classification of processes/sockets into groups
using rules; but is completely optional) and any code for new kinds of
groupings (other than tasks and sockets) that may be found useful to
control as a set in future.

This independence is a feature - it allows the controller code that is
deemed acceptable to the corresponding scheduler maintainer to be
integrated without being dependent on acceptance of other scheduler
modifications.

Of course, the core and user interface (rcfs) have to be included, but
they're not that large (subjective biased opinion of course, but
seriously, if there are suggestions on how we can make it even leaner,
we're open to ideas).



> I'd hate to see this in the kernel unless there's a very strong need
> for it and no way to solve it at a nicer layer of abstraction, e.g.
> userland virtual machines ala uml/umlinux.
>

Trying to achieve the same goals using abstractions built on top of
process-centric rlimits will not work for examples like a) or e).

Also, if we want to regulate resource consumption by groups of sockets
or other types of kernel objects, the wheel would need to be reinvented.

We believe that CKRM addresses both of the above concerns.






> -
> 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/
>

-
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:2.295 / U:0.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site