Re: [Xen-devel] Xen 4.2 Release Plan / TODO

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx]
> > >
> 
> > Libxl_tmem_destroy may take a long time as it has to walk
> > through and free some potentially very large data structures,
> > but it is only used at domain destruction.
> 
> Should libxl_tmem_destroy be a public function or should it solely be
> called from libxl_domain_destroy? I notice that there is an xl
> tmem-destroy so I presume the former?
> 
> We might consider adding a dummy ao_how to this one I suppose.

Bearing in mind that I haven't poked around in this
code for over 2 years, I *think* the only reason tmem_destroy
needs to exist at all is if tmem is broken.  The normal domain
termination process destroys any persistent tmem pools and
any ephemeral tmem pools will eventually "age out" as the
last of the pools' pages fall off the end of the LRU.

I think the tmem_destroy functionality pre-dates the
existence of tmem "freeable" memory* and was a way for
a toolset to force the hypervisor to free up the hypervisor
memory used by some or all ephemeral tmem pools.  Once the
tmem allocation/free process was directly linked into
alloc_heap_pages() in the hypervisor (see call to
tmem_relinquish_pages()), this forcing function was
no longer needed.

So, bottom line, I *think* it can be ripped out, or at least
for now removed from the definition of the stable xl API/UI.
The libxl.c routine libxl_tmem_destroy() could also be
removed if you like, but I guess I'd prefer to leave the
lower level droppings in xc.c and in the hypervisor in case
I am misremembering.

* http://xenbits.xensource.com/hg/xen-unstable.hg/rev/03063e309356

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel