[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Purpose of mem-max command

On Mon, 2015-10-12 at 11:10 +0200, Marco Guazzone wrote:
> On Mon, Oct 12, 2015 at 11:01 AM, Ian Campbell <ian.campbell@xxxxxxxxxx>
> wrote:
> > On Sun, 2015-10-11 at 19:47 +0100, Simon Hobson wrote:
> > > Bear in mind that I'm not even an advanced user ...
> > > 
> > > 
> > > On 11 Oct 2015, at 11:45, Marco Guazzone <marco.guazzone@xxxxxxxxx>
> > > wrote:
> > > 
> > > > What I don't understand is how to use it effectively.
> > > > Could you provide a practical example of how to use it?
> > > 
> > > I don't know if it works on an already running VM
> > 
> > You would need a kernel which supports memory hotplug and not just
> > ballooning. Support for memory hotplug is quite new in Xenified
> > mainline
> > Linux, I'm not sure when it was added. Hopefully the keywords will be
> > sufficient for some search engine.
> > [...]
> > 
> > > AIUI, when a machine (whether virtual or bare metal) starts up,
> > > certain
> > > memory structures (kernal tables) are setup based on the amount of
> > > memory
> > > installed.
> > 
> > Correct.
> > 
> > >  I assume that this constrains the machine from dynamically adding
> > > memory
> > > above what was present at startup - or in this context, configured by
> > > the
> > > maxmem argument to Xen.
> > 
> > Mostly correct, it's this "dynamically adding memory" (or more
> > accurately
> > "banks of memory") which then requires hotplug and not just regular
> > ballooning.
> > 
> > (You can, sort of, think of memory hotplug as being coarse grained and
> > ballooning more granular, kind of).
> > 
> > 
> > Ian.
> Dear all,
> Thank you for your replies.
> Your suggestions are clear to me, but I still don't understand the
> purpose "xl mem-max" command. :-)

It allows the hotplugging of additional memory banks.

When starting a guest with memory=X + maxmem=Y (where X<=Y) you can use "xl
mem-set" to balloon the guest up to a maximum of Y (and a minimum of some
OS specific minimum). This requires you to have a balloon driver in your
guest kernel.

If you want to increase to more than Y then you need to use xl mem-max to
increase the maximum memory to something greater by hotplugging additional
memory capacity, e.g. Z. Now you can use xl mem-set to balloon the guest up
to Z. This requires memory hotplug support in your guest in addition to the
balloon driver.

> Also , maybe I misunderstood the memory ballooning and the
> poplutae-on-demand techniques.

populate-on-demand is used for HVM guests in order to support memory<maxmem
until the guest's own balloon driver can be loaded and take over. It is
essential that the guest has a balloon driver and loads it ASAP on boot,
populate-on-demand is not intended to be used for the duration of a VM's
life, just at start of day.

> From this article,
>    https://blog.xenproject.org/2014/02/14/ballooning-rebooting-and-the-fe
> ature-youve-never-heard-of/
> it seems that the guest OS should think to have the maximum amount of
> RAM configured with "maxmen":
> Instead, from experiments (including the ones you suggested), the
> amount of memory the guest OS sees is the one configured with "memory"
> (in the configuration file) or set with "xl mem-set".
> For instance, in the Simon's example, the guest OS sees 512MB and not
> 2GB.

Simon's example was:
memory  = '512'
maxmem  = '2048'

So this is expected. The guest has 512M but the capability to balloon (via
mem-set) as high as 2GB.

> Similarly, in the Adam's example, the guest OS sees 8GB (or 10GB,
> after "xl mem-set 10g") and not 20GB.

Adam's example was:
maxmem = 20480
memory = 8192

So similarly the guest sees 8G until you xl mem-set 10G, at which point it
sees 10G. This guest could balloon as large as 20G using mem-set.

> In both cases, if I attempt to allocate (e.g., with calloc) an amount
> of memory greater than the one specified by "memory" config parameter
> or set with "xl mem-set" but less than specified by "maxmem" config
> parameter, the allocation fails (e.g., either calloc returns NULL or
> the process is killed).
> For instance, in the Adam's example, if I calloc 12GB of RAM, the
> process is killed.

Correct. The guest only has 8G or 10G in the example you gave.

> Is there a way in Xen to control/emulate on-demand memory provisioning
> like populate-on-demand does without doing memory hot-plug (i.e.,
> guest thinks to have X GB of RAM, but only Y < X GB of RAM is
> assigned)?

There is _experimental_ support for memsharing and mempaging in the Xen
source tree, but nothing production ready AFAIK.

There is also "tmem" and "selfballooning", which essentially cause a guest
to try and use less than the "target" it has been given using mem-set. I'm
not really sure how those work or what the status of them is.


Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.