All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryan Cumming <bodnar42@phalynx.dhs.org>
To: Jeff Dike <jdike@karaya.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Special Kernel Modification
Date: Sun, 4 Nov 2001 18:14:12 -0800	[thread overview]
Message-ID: <E160ZHB-0001Ae-00@localhost> (raw)
In-Reply-To: <200111050158.UAA05147@ccure.karaya.com>
In-Reply-To: <200111050158.UAA05147@ccure.karaya.com>

Hey Jeff,
> A virtual machine would be an administratively easy way of doing this.
>
> Let the 'app' be a VM with the real apps installed inside.  The users would
> effectively be confined to a *file* on the host, not merely their home
> directories.
>
> My (biased :-) recommendation would be User-mode Linux
> (http://user-mode-linux.sourceforge.net), but VMWare would work as
> well.

I'm afraid that would scale horribly on anything greater than a very modest 
load:

1) There is a fairly significant overhead due to running inside a VM, which 
would certainly pile up over multiple invocations. Besides the overhead of 
the VM, you have the have the additional overhead caused by such things as 
having multiple running kernels doing exactly the same thing, all running 
seperate copies of the required system daemons.
2) Upgrading/changing the system configuration would require modifying -all- 
of the VMs. This could be partially alleviated by using an NFS root, but then 
the overhead mentioned above becomes even more looming
3) Implicitly shared memory no longer works too well, and this is one of the 
reasons Unix is so strong as a terminal server:
  You have thirty people running StarOffice from /usr/bin, and because        
they've all mmap()ed the same binary, the read only portions are all shared,  
and will definitely stay in memory in the event of memory pressure. The same 
things goes for all the libraries and mmap()'ed data files StarOffice uses, 
including some pretty hefty ones such as glibc. Even many of the writable 
pages will be shared until someone decides to write to one of them, and then 
the writer will get a private copy.
  Now, try 30 people all running from VMs. They all must have a seperate copy 
of the otherwise sharable portions of StarOffice, and all of its 
dependancies. Memory pressure quickly rises, and it will start swapping out 
one copy of StarOffice in favour of an identical portion of another copy (!). 
System quickly becomes unusable. 

So, to summarize, you could use a VM, and it'd work well for containment, but 
it'd be pretty useless as far as performance, ease of administration, and 
scaling go. Comments?

-Ryan

  reply	other threads:[~2001-11-05  2:14 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-05  0:01 Special Kernel Modification Lonnie Cumberland
2001-11-05  0:19 ` Ryan Cumming
2001-11-05  0:29   ` lonnie
2001-11-05  1:04     ` Jan-Benedict Glaw
2001-11-05  3:04     ` Mike Fedyk
2001-11-06  0:34     ` Jorgen Cederlof
2001-11-06  0:38       ` lonnie
2001-11-05  0:22 ` Alan Cox
2001-11-05  0:39   ` Phil Sorber
2001-11-05  0:38 ` Rik van Riel
2001-11-05  1:04 ` Jeremy Jackson
2001-11-05  1:58 ` Jeff Dike
2001-11-05  2:14   ` Ryan Cumming [this message]
2001-11-05  4:02     ` Jeff Dike
2001-11-05  3:13       ` Ryan Cumming
2001-11-05  5:52         ` Jeff Dike
2001-11-05  5:30           ` Ryan Cumming
2001-11-05 14:22             ` Jeff Dike
2001-11-05 16:53           ` Andrea Arcangeli
2001-11-05 20:18             ` Jeff Dike
2001-11-05 19:05               ` Andrea Arcangeli
  -- strict thread matches above, loose matches on Subject: below --
2001-11-05  0:37 John Weber
     [not found] <E160aCK-0001Fs-00@localhost.suse.lists.linux.kernel>
     [not found] ` <200111050552.AAA06451@ccure.karaya.com.suse.lists.linux.kernel>
2001-11-05  6:22   ` Andi Kleen

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=E160ZHB-0001Ae-00@localhost \
    --to=bodnar42@phalynx.dhs.org \
    --cc=jdike@karaya.com \
    --cc=linux-kernel@vger.kernel.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 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.