public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: Gerrit Huizenga <gh@us.ibm.com>
Cc: Hubertus Franke <frankeh@watson.ibm.com>,
	ckrm-tech@lists.sourceforge.net,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	LSE <lse-tech@lists.sourceforge.net>,
	vserver@list.linux-vserver.org, Andrew Morton <akpm@osdl.org>,
	Rik van Riel <riel@redhat.com>,
	pagg@oss.sgi.com
Subject: Re: [ckrm-tech] Re: [RFC][patch 00/21] PID Virtualization: Overview and Patches
Date: Thu, 15 Dec 2005 12:02:41 -0800	[thread overview]
Message-ID: <1134676961.22525.72.camel@localhost> (raw)
In-Reply-To: <E1Emz6c-0006c3-00@w-gerrit.beaverton.ibm.com>

On Thu, 2005-12-15 at 11:49 -0800, Gerrit Huizenga wrote:
> I think perhaps this could also be the basis for a CKRM "class"
> grouping as well.  Rather than maintaining an independent class
> affiliation for tasks, why not have a class devolve (evolve?) into
> a "container" as described here.

Wasn't one of the grand schemes of CKRM to be able to have application
instances be shared?  For instance, running a single DB2, Oracle, or
Apache server, and still accounting for all of the classes separately.
If so, that wouldn't work with a scheme that requires process
separation.

But, sharing the application instances is probably mostly (only)
important for databases anyway.  I would imagine that most of the
overhead in a server like an Apache instance is for the page cache for
content, as well as a bit for Apache's executables themselves.  The
container schemes should be able to share page cache for both cases.
The main issues would be managing multiple configurations, and the
increased overhead from having more processes around than with a single
server.

There might also be some serious restrictions on containerized
applications.  For instance, taking a running application, moving it out
of one container, and into another might not be feasible.  Is this
something that is common or desired in the current CKRM framework?

-- Dave


  reply	other threads:[~2005-12-15 20:02 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-15 14:35 [RFC][patch 00/21] PID Virtualization: Overview and Patches Hubertus Franke
2005-12-15 14:35 ` [RFC][patch 01/21] PID Virtualization: const parameter for process group Hubertus Franke
2005-12-15 14:35 ` [RFC][patch 02/21] PID Virtualization: task virtual pid access functions Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 03/21] PID Virtualization: return virtual pids where required Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 04/21] PID Virtualization: return virtual process group ids Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 05/21] PID Virtualization: code enhancements for virtual pids in /proc Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 06/21] PID Virtualization: Define pid_to_vpid functions Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 07/21] PID Virtualization: Use pid_to_vpid conversion functions Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 08/21] PID Virtualization: file owner pid virtualization Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 09/21] PID Virtualization: define vpid_to_pid functions Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 10/21] PID Virtualization: Use " Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 11/21] PID Virtualization: use vpgid_to_pgid function Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 12/21] PID Virtualization: Context for pid_to_vpid conversition functions Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 13/21] PID Virtualization: Documentation Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 14/21] PID Virtualization: pidspace Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 15/21] PID Virtualization: container object and functions Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 16/21] PID Virtualization: container attach/detach calls Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 17/21] PID Virtualization: /proc/container filesystem Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 18/21] PID Virtualization: Implementation of low level virtualization functions Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 19/21] PID Virtualization: Handle special case vpid return cases Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 20/21] PID Virtualization: per container /proc filesystem Hubertus Franke
2005-12-15 14:36 ` [RFC][patch 21/21] PID Virtualization: pidspace parent : signal behavior Hubertus Franke
2005-12-15 19:49 ` [RFC][patch 00/21] PID Virtualization: Overview and Patches Gerrit Huizenga
2005-12-15 20:02   ` Dave Hansen [this message]
2005-12-15 20:12     ` [ckrm-tech] " Gerrit Huizenga
2005-12-15 22:52     ` Matt Helsley
2005-12-15 22:02   ` Hubertus Franke
2005-12-16  2:20   ` [ckrm-tech] " Matt Helsley
2005-12-16  3:28     ` Gerrit Huizenga
2005-12-16 17:35       ` Dave Hansen
2005-12-16 20:45         ` Gerrit Huizenga
2005-12-16 21:10           ` Dave Hansen
2005-12-16 23:40             ` Hubertus Franke
2005-12-16 23:47         ` Hubertus Franke
2005-12-17  1:18           ` Matt Helsley
2005-12-17  3:03             ` [Lse-tech] " Hubertus Franke
2005-12-17  1:38       ` Matt Helsley

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=1134676961.22525.72.camel@localhost \
    --to=haveblue@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=ckrm-tech@lists.sourceforge.net \
    --cc=frankeh@watson.ibm.com \
    --cc=gh@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=pagg@oss.sgi.com \
    --cc=riel@redhat.com \
    --cc=vserver@list.linux-vserver.org \
    /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