From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: Re: Xen 4.2 Release Plan / TODO Date: Fri, 13 Apr 2012 08:28:19 -0700 (PDT) Message-ID: <4c2f7fca-dda2-4598-aaab-3a6a3fe532cd@default> References: <1333362402.25602.36.camel@zakaz.uk.xensource.com> <20357.44324.27939.514126@mariner.uk.xensource.com> <1334216141.12209.236.camel@dagon.hellion.org.uk> <1334217564.12209.250.camel@dagon.hellion.org.uk> <2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default> <1334249132.16387.147.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1334249132.16387.147.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Zhigang Wang , Ian Jackson , xen-devel List-Id: xen-devel@lists.xenproject.org > From: Ian Campbell [mailto:Ian.Campbell@citrix.com] > > > > > > 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