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: echo@xxxxxxxxxxxx, Luke S Crawford <lsc@xxxxxxxxx>
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: Sun, 31 May 2009 12:48:45 -0700 (PDT)
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 31 May 2009 12:49:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1243789251.5369.37.camel@xxxxxxxxxxxxxxxxxxxxx>
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
> > So in a large way, I think Dan is correct. If a client 
> bought the use of
> > memory and barely uses it, I'd rather give them a discount 
> for giving
> > some back, enabling me to set up another domain on that 
> node. But don't
> > get me wrong, I'd never dream of doing that 'automagically' :)
> 
> I meant to add, if an overcommit feature could just make and log
> suggestions, it would eliminate a ton of userspace hackery. Thus, it
> would be very useful to hosts (albeit in a neutered form).
> 
> Most hosts would gladly deal with sed, grep and awk vs libxc and
> libxs :)

Tmem with self-ballooning can be controlled on a guest-by-guest
basis, dynamically and with fairly good granularity.  So
you need not turn overcommit "on" or "off".  And there is no
hypervisor-based swapping which is invisible to the guest;
overcommit requires guests to provide swap space and
if they don't balloon down (voluntarily) and don't exceed
their RAM, they don't use it.

Picture this (and assume tools exist to help you measure
and manage it):  Each user is billed only for the resources
they use, including RAM.  RAM "optimization" can be controlled
by the user via a menu (or slider bar for more granularity);
at one extreme, RAM (and more specifically page cache) is
aggressively reduced... but only if another VM is demanding
it.  On the other extreme, fixed maximum RAM is fully owned
by the user, and it sits idle if not in use.  The user
can choose dynamically whether to pay more for fast responsiveness,
or to pay less and surrender RAM if needed elsewhere, with
some probability for slower responsiveness.

In other words, this is like the option that some power
utilities are providing to give you a discount if you are
willing to let them shut off your air conditioning or
water heater at peak load.

Note that these tools DON'T exist today... and I don't plan
on writing them.  I'm just working at the hypervisor level
to ensure that memory utilization can be more effective and
flexible (and measurable when the flexibility is used).

Does that sound more attractive to an IAAS provider?


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

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