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/
Home Products Support Community News


[Xen-devel] RE: [RFC PATCH 0/4] (Take 2): transcendent memory ("tmem") f

> From: Rik van Riel [mailto:riel@xxxxxxxxxx]

> Dan Magenheimer wrote:
> > "Preswap" IS persistent, but for various reasons may not always be
> > available for use, again due to factors that may not be 
> visible to the
> > kernel (but, briefly, if the kernel is being "good" and has 
> shared its
> > resources nicely, then it will be able to use preswap, else 
> it will not).
> > Once a page is put, a get on the page will always succeed. 
> What happens when all of the free memory on a system
> has been consumed by preswap by a few guests?
> Will the system be unable to start another guest,

The default policy (and only policy implemented as of now) is
that no guest is allowed to use more than max_mem for the
sum of directly-addressable memory (e.g. RAM) and persistent
tmem (e.g. preswap).  So if a guest is using its default
memory==max_mem and is doing no ballooning, nothing can
be put in preswap by that guest.
> or is there some way to free the preswap memory?

Yes and no.  There is no way externally to free preswap
memory, but an in-guest userland root service can write to sysfs
to affect preswap size.  This essentially does a partial
swapoff on preswap if there is sufficient (directly addressable)
guest RAM available.  (I have this prototyped as part of
the xenballoond self-ballooning service in xen-unstable.)


Xen-devel mailing list