public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Srivatsa Vaddagiri <vatsa@in.ibm.com>
To: "Paul Menage" <menage@google.com>
Cc: "Paul Jackson" <pj@sgi.com>,
	dev@openvz.org, sekharan@us.ibm.com,
	ckrm-tech@lists.sourceforge.net, balbir@in.ibm.com,
	haveblue@us.ibm.com, linux-kernel@vger.kernel.org,
	matthltc@us.ibm.com, dipankar@in.ibm.com, rohitseth@google.com
Subject: Re: [ckrm-tech] [RFC] Resource Management - Infrastructure choices
Date: Mon, 6 Nov 2006 18:19:48 +0530	[thread overview]
Message-ID: <20061106124948.GA3027@in.ibm.com> (raw)
In-Reply-To: <6599ad830611011537i2de812fck99822d3dd1314992@mail.gmail.com>

On Wed, Nov 01, 2006 at 03:37:12PM -0800, Paul Menage wrote:
> I saw your example, but can you give a concrete example of a situation
> when you might want to do that?

Paul,
	Firstly, after some more thought on this, we can use your current
proposal, if it makes the implementation simpler.

Secondly, regarding how separate grouping per-resource *maybe* usefull,
consider this scenario.

A large university server has various users - students, professors,
system tasks etc. The resource planning for this server could be on these lines:

	CPU : 		Top cpuset 
			/	\   
		CPUSet1 	CPUSet2
		   |		  |
		(Profs)		(Students)

		In addition (system tasks) are attached to topcpuset (so
		that they can run anywhere) with a limit of 20%

	Memory : Professors (50%), students (30%), system (20%)

	Disk : Prof (50%), students (30%), system (20%)

	Network : WWW browsing (20%), Network File System (60%), others (20%)
				/ \
 			Prof (15%) students (5%)

Browsers like firefox/lynx go into the WWW network class, while (k)nfsd go 
into NFS network class.

At the same time firefox/lynx will share an appropriate CPU/Memory class 
depending on who launched it (prof/student).

If we had the ability to write pids directly to these resource classes,
then admin can easily setup a script which receives exec notifications
and depending on who is launching the browser he can 
	
	# echo browser_pid > approp_resource_class

With your proposal, he now would have to create a separate container for
every browser launched and associate it with approp network and other
resource class. This may lead to proliferation of such containers.

Also lets say that the administrator would like to give enhanced network
access temporarily to a student's browser (since it is night and the user
wants to do online gaming :)  OR give one of the students simulation
apps enhanced CPU power, 

With ability to write pids directly to resource classes, its just a
matter of :

	# echo pid > new_cpu/network_class
	(after some time)
	# echo pid > old_cpu/network_class

Without this ability, he will have to split the container into a
separate one and then associate the container with the new resource
classes.

So yes, the end result is perhaps achievable either way, the big
different I see is the ease of use.

> For simplicity combined with flexibility, I think I still favour the
> following model:
> 
> - all processes are a member of one container
> - for each resource type, each container is either in the same
> resource node as its parent or a freshly child node of the parent
> resource node (determined at container creation time)
> 
> This is a subset of my more complex model, but it's pretty easy to
> understand from userspace and to implement in the kernel.

If this model makes the implementation simpler, then I am for it, until
we have gained better insight on its use.

> What objections do you have to David's suggestion hat if you want some
> processes in a container to be in one resource node and others in
> another resource node, then you should just subdivide into two
> containers, such that all processes in a container are in the same set
> of resource nodes?

One observation is the ease of use (as some of the examples above
point out). Other is that it could lead to more containers than
necessary.

-- 
Regards,
vatsa

  reply	other threads:[~2006-11-06 12:50 UTC|newest]

Thread overview: 135+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-30 10:33 [RFC] Resource Management - Infrastructure choices Srivatsa Vaddagiri
2006-10-30 10:34 ` RFC: Memory Controller Balbir Singh
2006-10-30 11:04   ` Paul Menage
2006-10-30 13:27     ` [ckrm-tech] " Balbir Singh
2006-10-30 18:14       ` Paul Menage
2006-10-31 17:07         ` Balbir Singh
2006-10-31 17:22           ` Paul Menage
2006-10-31 18:16             ` Badari Pulavarty
2006-11-01  7:05             ` Balbir Singh
2006-11-01  7:07               ` Paul Menage
2006-11-01  7:44                 ` Balbir Singh
2006-11-01 12:23                   ` Paul Jackson
2006-11-02  0:09                     ` Paul Menage
2006-11-02  0:39                       ` Paul Jackson
2006-10-30 15:58   ` Pavel Emelianov
2006-10-30 17:39     ` Balbir Singh
2006-10-30 18:07       ` Balbir Singh
2006-10-31  8:57         ` Pavel Emelianov
2006-10-31  9:19           ` Balbir Singh
2006-10-31  9:25             ` Pavel Emelianov
2006-10-31 10:10               ` Balbir Singh
2006-10-31 10:19                 ` Pavel Emelianov
2006-10-31  9:42             ` Andrew Morton
2006-10-31 10:36               ` Balbir Singh
2006-10-31  8:48       ` Pavel Emelianov
2006-10-31 10:54         ` Balbir Singh
2006-10-31 11:15           ` Pavel Emelianov
2006-10-31 12:39             ` Balbir Singh
2006-10-31 14:19               ` Pavel Emelianov
2006-10-31 16:54             ` Paul Menage
2006-11-01  6:00             ` David Rientjes
2006-11-01  8:05               ` Pavel Emelianov
2006-11-01  8:35                 ` David Rientjes
2006-10-31 17:04         ` Dave Hansen
2006-11-01  7:57           ` Pavel Emelianov
2006-10-30 18:20     ` Paul Menage
2006-10-30 21:38       ` Paul Jackson
2006-10-30 10:43 ` [RFC] Resource Management - Infrastructure choices Paul Jackson
2006-10-30 14:19   ` [ckrm-tech] " Pavel Emelianov
2006-10-30 14:29     ` Paul Jackson
2006-10-30 17:09   ` Srivatsa Vaddagiri
2006-10-30 17:16     ` Dave McCracken
2006-10-30 18:07       ` Paul Menage
2006-10-30 20:41         ` Paul Jackson
2006-10-30 10:51 ` Paul Menage
2006-10-30 11:06   ` [ckrm-tech] " Paul Jackson
2006-10-30 12:07     ` Paul Menage
2006-10-30 12:28       ` Paul Jackson
2006-10-30 11:15   ` Paul Jackson
2006-10-30 12:04     ` Paul Menage
2006-10-30 12:27       ` Paul Jackson
2006-10-30 17:53         ` Paul Menage
2006-10-30 20:36           ` Paul Jackson
2006-10-30 20:47             ` Paul Menage
2006-10-30 20:56               ` Paul Jackson
2006-10-30 21:03               ` Paul Menage
2006-10-31 11:53               ` Srivatsa Vaddagiri
2006-10-31 13:31                 ` Srivatsa Vaddagiri
2006-10-31 16:46                 ` Paul Menage
2006-11-01 17:25                   ` Srivatsa Vaddagiri
2006-11-01 23:37                     ` Paul Menage
2006-11-06 12:49                       ` Srivatsa Vaddagiri [this message]
2006-11-06 20:23                         ` Paul Menage
2006-11-07 13:20                           ` Srivatsa Vaddagiri
2006-11-07 18:41                           ` Paul Jackson
2006-11-07 19:07                             ` Paul Menage
2006-11-07 19:11                               ` Paul Jackson
2006-11-07 19:24                                 ` Paul Menage
2006-11-07 19:58                                   ` Paul Jackson
2006-11-07 20:00                                     ` Paul Menage
2006-11-07 20:02                               ` Paul Jackson
2006-11-08  2:47                                 ` Matt Helsley
2006-11-07 20:34                               ` Paul Jackson
2006-11-07 20:41                                 ` Paul Menage
2006-11-07 21:50                                   ` Paul Jackson
2006-11-07 22:21                               ` Paul Menage
2006-11-08  3:15                                 ` Paul Jackson
2006-11-08  4:15                                   ` Paul Menage
2006-11-08  4:16                                     ` Paul Jackson
2006-11-08 11:22                                     ` Paul Jackson
2006-11-08  5:12                                   ` Srivatsa Vaddagiri
2006-11-08  5:36                                     ` Paul Jackson
2006-11-09  5:39                                       ` Balbir Singh
2006-11-08 19:25                                     ` Chris Friesen
2006-11-09  3:54                                       ` Srivatsa Vaddagiri
2006-11-10 14:57                           ` Srivatsa Vaddagiri
2006-11-01  4:39               ` David Rientjes
2006-11-01  9:50                 ` Paul Jackson
2006-11-01  9:58                   ` David Rientjes
2006-11-01 15:59                 ` Srivatsa Vaddagiri
2006-11-01 16:31                   ` Srivatsa Vaddagiri
2006-11-01 21:05                   ` David Rientjes
2006-11-01 23:43                     ` Paul Menage
2006-11-01 18:19                 ` Srivatsa Vaddagiri
2006-11-01 17:33   ` Srivatsa Vaddagiri
2006-11-01 21:18     ` Chris Friesen
2006-11-01 23:01       ` [Devel] " Kir Kolyshkin
2006-11-02  0:31         ` Matt Helsley
2006-11-02  8:34           ` Kir Kolyshkin
2006-11-01 23:48       ` Paul Menage
2006-11-02  3:28         ` Chris Friesen
2006-11-02  7:40           ` Paul Menage
2006-10-30 14:08 ` Pavel Emelianov
2006-10-30 14:23   ` Paul Jackson
2006-10-30 14:38     ` Pavel Emelianov
2006-10-30 15:18       ` Paul Jackson
2006-10-30 15:26         ` Pavel Emelianov
2006-10-31  0:26           ` Matt Helsley
2006-10-31  8:34             ` Pavel Emelianov
2006-10-31 16:33           ` Chris Friesen
2006-10-30 18:01   ` Paul Menage
2006-10-31  8:31     ` Pavel Emelianov
2006-10-31 16:34       ` Paul Menage
2006-10-31 16:57         ` Srivatsa Vaddagiri
2006-11-01  7:58         ` Pavel Emelianov
2006-10-31 16:34   ` Srivatsa Vaddagiri
2006-11-01  8:01     ` Pavel Emelianov
2006-11-01 16:04       ` Matt Helsley
2006-11-01 17:51         ` Srivatsa Vaddagiri
2006-11-01 17:50       ` Srivatsa Vaddagiri
2006-11-02  8:42         ` Pavel Emelianov
2006-11-03  1:29           ` David Rientjes
2006-11-01  9:30 ` Pavel Emelianov
2006-11-01  9:53   ` David Rientjes
2006-11-01 22:23     ` Matt Helsley
2006-11-01 18:12   ` Srivatsa Vaddagiri
2006-11-01 22:19     ` Matt Helsley
2006-11-01 23:50       ` Paul Menage
2006-11-02  0:30         ` Matt Helsley
2006-11-02  5:33           ` Balbir Singh
2006-11-02  9:08         ` Pavel Emelianov
2006-11-02 11:26           ` Matt Helsley
2006-11-02 13:04             ` Pavel Emelianov
2006-11-03  1:29               ` David Rientjes
2006-11-02  8:52     ` Pavel Emelianov

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=20061106124948.GA3027@in.ibm.com \
    --to=vatsa@in.ibm.com \
    --cc=balbir@in.ibm.com \
    --cc=ckrm-tech@lists.sourceforge.net \
    --cc=dev@openvz.org \
    --cc=dipankar@in.ibm.com \
    --cc=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthltc@us.ibm.com \
    --cc=menage@google.com \
    --cc=pj@sgi.com \
    --cc=rohitseth@google.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox