WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: Distro kernel and 'virtualization server' vs. 'server that sometimes

To: Luke S Crawford <lsc@xxxxxxxxx>, echo@xxxxxxxxxxxx
Subject: RE: Distro kernel and 'virtualization server' vs. 'server that sometimes runs virtual instances' rant (was: Re: [Xen-devel] Re: [GIT PULL] Xen APIC hooks (with io_apic_ops))
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 29 May 2009 06:42:26 -0700 (PDT)
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 29 May 2009 06:43:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <m3bppc3m09.fsf@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> With the move to Xen, suddenly the heavy user was the only user
> seeing the slowness.    Now the heavy user has the option of paying
> me more money for more ram to use as disk cache, or of dealing with it
> being slow.  Light users had no more trouble.  Log in once 
> every 3 months?
> your /etc/passwd is still cached from last time.  

Am I understanding this correctly that you are "renting" a
fixed partition of physical RAM that (assuming the physical
server never reboots) persistently holds one VSP customer's
VM's memory forever, never saved to disk?

Although I can see this being advantageous for some users,
no matter how cheap RAM is, having RAM sit "idle" for months
(or even minutes) seems a dreadful waste of resources,
which is either increasing the price of the service or the
cost to the provider for a very small benefit for a
small number of users.  I see it as akin to every VM
computing pi in a background process because, after all,
the CPU has nothing better to do if it was going to be
idle anyway.

While I can see how the current sorry state of memory management
by OS's and hypervisors might lead to this business decision,
my goal is to make RAM a much more "renewable" resource.
The same way CPU's are adding power management so that
they can be shut down when idle even for extremely small
periods of time to conserve resources, I'd like to see
"idle memory" dramatically reduced.  Self-ballooning and
tmem are admittedly only a step in that direction, but
at least it is (I hope) the right direction.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>