From: Srivatsa Vaddagiri <vatsa@in.ibm.com>
To: Chandra Seetharaman <sekharan@us.ibm.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
Andrew Morton <akpm@osdl.org>,
sam@vilain.net, dev@openvz.org, efault@gmx.de, mingo@elte.hu,
pwil3058@bigpond.net.au, balbir@in.ibm.com,
linux-kernel@vger.kernel.org, maeda.naoaki@jp.fujitsu.com,
kurosawa@valinux.co.jp,
ckrm-tech <ckrm-tech@lists.sourceforge.net>
Subject: Re: Resource Management Requirements (was "[RFC] CPU controllers?")
Date: Tue, 20 Jun 2006 11:10:27 +0530 [thread overview]
Message-ID: <20060620054027.GA1083@in.ibm.com> (raw)
In-Reply-To: <1150743803.30013.37.camel@linuxchandra>
On Mon, Jun 19, 2006 at 12:03:23PM -0700, Chandra Seetharaman wrote:
> On Sun, 2006-06-18 at 17:28 +1000, Nick Piggin wrote:
>
> > OK... let me put it more clearly. What are the requirements?
At a very broad-level, all the requirements pointed by Chandra below boil down
to the requirement of providing guaranteed CPU usage for a group of
tasks and the ability of limiting (hard or soft) CPU usage of other group of
tasks.
At a finer-level, this broad requirement could be interpreted and implemented
in a number of ways (ex: by having kernel support only task-level limit and
implementing group-level in user-space etc) and thats what this RFC was
about - to discuss what minimal kernel support would be needed to
support the above broad requirement!
> Nick,
>
> Here are some requirements we(Resource Groups aka CKRM) are working
> towards (Note that this is not limited to CPU alone):
>
> In a enterprise environment:
> - Ability to group applications into their importance levels and assign
> appropriate amount of resources to them.
> - In case of server consolidation, ability to allocate and control
> resources to a specific group of applications. Ability to
> account/charge according to their usages.
> - manage multiple departments in a single OS instance with ability to
> allocate and control resources department wise (similar to above
> requirement :)
> - ability to guarantee "time to complete" for a specific user
> request (by controlling resource usage starting from the web server
> to the database server).
> - In case of ISPs and ASPs, ability to guarantee/limit usages to
> independent clients (in a single OS instance).
> - Ability to control runaway processes from bringing down the system
> response (DoS attacks, fork bombs etc.,)
>
> In a university environment (can be treated as a subset of enterprise
> requirements above):
> - Ability to limit resource consumption at individual user level.
> - Ability to control runaway processes.
> - Ability for a user to manage resources allocated to them (as
> explained in the desktop environment below).
>
> In a desktop environment:
> - Ability to control resource usage of a set of applications
> (ex: infamous updatedb issue).
> - Ability to run different loads and get the expected result (like
> checking emails or browsing Internet while compilation is in
> progress)
>
> Generic:
> Provide these resource management capabilities with less overhead on
> overall system performance.
--
Regards,
vatsa
next prev parent reply other threads:[~2006-06-20 5:40 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-15 13:46 [RFC] CPU controllers? Srivatsa Vaddagiri
2006-06-15 21:52 ` Sam Vilain
2006-06-15 23:30 ` Peter Williams
2006-06-16 0:42 ` Matt Helsley
2006-06-17 8:48 ` Nick Piggin
2006-06-17 15:55 ` Balbir Singh
2006-06-17 16:48 ` Srivatsa Vaddagiri
2006-06-18 5:06 ` Nick Piggin
2006-06-18 5:53 ` Sam Vilain
2006-06-18 6:11 ` Nick Piggin
2006-06-18 6:40 ` Sam Vilain
2006-06-18 7:17 ` Nick Piggin
2006-06-18 6:42 ` Andrew Morton
2006-06-18 7:28 ` Nick Piggin
2006-06-19 19:03 ` Resource Management Requirements (was "[RFC] CPU controllers?") Chandra Seetharaman
2006-06-20 5:40 ` Srivatsa Vaddagiri [this message]
2006-06-18 7:36 ` [RFC] CPU controllers? Mike Galbraith
2006-06-18 7:49 ` Nick Piggin
2006-06-18 7:49 ` Nick Piggin
2006-06-18 9:09 ` Andrew Morton
2006-06-18 9:49 ` Mike Galbraith
2006-06-19 6:28 ` Mike Galbraith
2006-06-19 6:35 ` Andrew Morton
2006-06-19 6:46 ` Mike Galbraith
2006-06-19 18:21 ` Chris Friesen
2006-06-20 6:20 ` Mike Galbraith
2006-06-18 7:18 ` Srivatsa Vaddagiri
2006-06-19 2:07 ` Sam Vilain
2006-06-19 7:04 ` MAEDA Naoaki
2006-06-19 8:19 ` Sam Vilain
2006-06-19 8:41 ` MAEDA Naoaki
2006-06-19 8:53 ` Sam Vilain
2006-06-19 21:44 ` MAEDA Naoaki
2006-06-19 18:14 ` Chris Friesen
2006-06-19 19:11 ` Chandra Seetharaman
2006-06-19 20:28 ` Chris Friesen
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=20060620054027.GA1083@in.ibm.com \
--to=vatsa@in.ibm.com \
--cc=akpm@osdl.org \
--cc=balbir@in.ibm.com \
--cc=ckrm-tech@lists.sourceforge.net \
--cc=dev@openvz.org \
--cc=efault@gmx.de \
--cc=kurosawa@valinux.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=maeda.naoaki@jp.fujitsu.com \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=pwil3058@bigpond.net.au \
--cc=sam@vilain.net \
--cc=sekharan@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.