LKML Archive on
help / color / mirror / Atom feed
From: Andrew Morton <>
To: Herbert Poetzl <>
Cc: "Eric W. Biederman" <>,,,
	Dave Hansen <>
Subject: Re: Linux-VServer example results for sharing vs. separate mappings ...
Date: Fri, 23 Mar 2007 21:42:35 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, 23 Mar 2007 20:30:00 +0100 Herbert Poetzl <> wrote:

> Hi Eric!
> Hi Folks!
> here is a real world example result from one of my tests
> regarding the benefit of sharing over separate memory
> the setup is quite simple, a typical machine used by
> providers all over the world, a dual Pentium D 3.2GHz
> with 4GB of memory and a single 160GB SATA disk running
> a Linux-VServer kernel (
> the Guest systems used are Mandriva 2007 guests with
> syslog, crond, sshd, apache, postfix and postgresql
> installed and running (all in all 17 processes per guest)
> the disk space used by one guests is roughly 148MB
> in addition to that, a normal host system is running
> with a few daemons (like sshd, httpd, postfix ...)
> the first test setup is starting 200 of those guests
> one after the other and measuring the memory usage
> before and after the guest did start, as well as 
> recording the time used to start them ...
> this is done right after the machine was rebooted, in
> one test with 200 separate guests (i.e. 200 x 148MB) 
> and in a second run with 200 unified guests (which
> means roughly 138MB of shared files)

Please define your terms.  What is a "separated guest", what is a "unified
guest" and how do they differ?

If a "separated" guest is something in which separate guests will use
distinct physical pages to cache the contents of /etc/passwd (ie: a separate
filesystem per guest) then I don't think that's interesting information,

Because nobody (afaik) is proposing that pagecache be duplicated across
instances in this fashion.

We obviously must share pagecache across instances - if we didn't want to
do that then we could do something completely dumb such as use
xen/kvm/vmware/etc ;)

The issue with pagecache (afaik) is that if we use containers based on
physical pages (an approach which is much preferred by myself) then we can
get in a situation where a pagecache page is physically in container A, is
not actually used by any process in container A, but is being releatedly
referenced by processes which are in other containers and hence unjustly
consumes resources in container A.   How significant a problem this is likely
to be I do not know.  And there are perhaps things which we can do about it.

  reply	other threads:[~2007-03-24  5:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-23 19:30 Linux-VServer example results for sharing vs. separate mappings Herbert Poetzl
2007-03-24  5:42 ` Andrew Morton [this message]
2007-03-24 18:38   ` Herbert Poetzl
2007-03-24 20:19     ` Andrew Morton
2007-03-25  2:21       ` Herbert Poetzl
2007-03-25  4:29         ` Andrew Morton
2007-03-25 14:40           ` Herbert Poetzl
2007-03-28  1:22         ` Ethan Solomita
2007-03-25  9:50       ` Balbir Singh
2007-03-25 18:51         ` Andrew Morton
2007-03-26  2:36           ` Balbir Singh
2007-03-26  5:26             ` Andrew Morton
2007-03-26  6:05               ` Balbir Singh
2007-03-26  9:26       ` [Devel] " Kirill Korotaev
     [not found] <>
     [not found] ` <>
     [not found]   ` <>
     [not found]     ` <>
     [not found]       ` <>
     [not found]         ` <>
2007-03-29  7:24           ` Bodo Eggert

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:

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

  git send-email \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).