public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chandra Seetharaman <sekharan@us.ibm.com>
To: Al Boldi <a1426z@gawab.com>
Cc: Matt Helsley <matthltc@us.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [ckrm-tech] [RFC] [PATCH 00/12] CKRM after a major overhaul
Date: Fri, 21 Apr 2006 22:46:40 -0700	[thread overview]
Message-ID: <1145684800.21231.30.camel@linuxchandra> (raw)
In-Reply-To: <200604220708.40018.a1426z@gawab.com>

On Sat, 2006-04-22 at 07:08 +0300, Al Boldi wrote:

> i.e: it should be possible to run the RCs w/o CKRM.
> 
> The current design pins the RCs on CKRM, when in fact this is not necessary.  
> One way to decouple them, could be to pin them against pid, thus allowing an 
> RC to leverage the pid hierarchy w/o the need for CKRM.  And only when finer 
> RM control is necessary, should CKRM come into play, by dynamically 
> adjusting the RC to achieve the desired effect.

This model works well in universities, where you associate some resource
when a student logs in, or a virtualised environment (like a UML or
vserver), where you attach resource to the root process.

It doesn't work with web servers, database servers etc.,, where the main
application will be forking tasks for different set of end users. In
that case you have to group tasks that are not related to one another
and attach resources to them.

Having a unified interface gives the system administrator ability to
group the tasks as they see them in real life (a department or important
transactions or just critical apps in a desktop).

It also has the added advantage that the resource controller writer do
not have to spend their time in coming up with an interface for their
controller. On the other hand if they do, the user finally ends up with
multiple interface (/proc, sysfs, configfs, /dev etc.,) to do their
resource management.

> 
> Thanks!
> 
> --
> Al
> 
-- 

----------------------------------------------------------------------
    Chandra Seetharaman               | Be careful what you choose....
              - sekharan@us.ibm.com   |      .......you may get it.
----------------------------------------------------------------------



  parent reply	other threads:[~2006-04-22 19:10 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-21 19:07 [ckrm-tech] [RFC] [PATCH 00/12] CKRM after a major overhaul Al Boldi
2006-04-21 22:04 ` Matt Helsley
     [not found]   ` <200604220708.40018.a1426z@gawab.com>
2006-04-22  5:46     ` Chandra Seetharaman [this message]
2006-04-22 20:40       ` Al Boldi
2006-04-23  2:33         ` Matt Helsley
2006-04-23 11:22           ` Al Boldi
2006-04-24 18:23             ` Chandra Seetharaman
2006-04-21 22:09 ` Chandra Seetharaman
  -- strict thread matches above, loose matches on Subject: below --
2006-04-21  2:24 sekharan
2006-04-21 14:49 ` [ckrm-tech] " Dave Hansen
2006-04-21 16:58   ` Chandra Seetharaman
2006-04-21 22:57     ` Andrew Morton
2006-04-22  1:48       ` Chandra Seetharaman
2006-04-22  2:13         ` Andrew Morton
2006-04-22  2:20           ` Matt Helsley
2006-04-22  2:33             ` Andrew Morton
2006-04-22  5:28           ` Chandra Seetharaman
2006-04-24  1:10             ` KUROSAWA Takahiro
2006-04-24  4:39               ` Kirill Korotaev
2006-04-24  5:41                 ` KUROSAWA Takahiro
2006-04-24  6:45                   ` Kirill Korotaev
2006-04-24  7:12                     ` KUROSAWA Takahiro
2006-04-24  5:18             ` Hirokazu Takahashi
2006-04-25  1:42               ` Chandra Seetharaman
2006-04-23  6:52           ` Paul Jackson
2006-04-23  9:31             ` Matt Helsley
2006-04-28  1:58           ` Chandra Seetharaman
2006-04-28  6:07             ` Kirill Korotaev
2006-04-28 17:57               ` Chandra Seetharaman
2006-04-24  1:47         ` Hirokazu Takahashi
2006-04-24 20:42           ` Shailabh Nagar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1145684800.21231.30.camel@linuxchandra \
    --to=sekharan@us.ibm.com \
    --cc=a1426z@gawab.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthltc@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox