> > 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
|
Home