From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Desnoyers Subject: Re: LTTng-Xen Buffer shared between the hypervisor and a dom0 process Date: Fri, 9 Mar 2007 22:02:30 -0500 Message-ID: <20070310030230.GC9323@Krystal> References: <20070308193025.GA20510@Krystal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org * Keir Fraser (keir@xensource.com) wrote: > On 8/3/07 19:30, "Mathieu Desnoyers" wrote: > > > lttctl-xen -r (finalize buffers, signal lttd-xen, decrement refcount) > > (lttd-xen : writes the last subbuffers. decrement refcount, ressources are > > freed) > > > > If no lttd-xen is mapping the buffers, we simply free then upon > > lttctl-xen -r. > > Okay, I get you. But what should happen if someone *is* mapping the buffers > when lttctl-xen -r is invoked? Is that an error condition, or is the > implementation supposed to reap the buffers 'as soon as possible' (i.e., > when the last mapping goes away)? > Ideally it would be ASAP. Here are the scenarios : Upon lttctl-xen -r, either 1 - Only Xen maps the buffers Decrement refcount We free then 2 - Xen and one lttd-xen process holds a mapping to the buffers We decrement a refcount, do not free them : lttd-xen still reads them. 3 - Xen and potentially many lttd-xen processes could map the buffers We decrement a refcount, do not free them : lttd-xen still reads them. Upon lttd-xen exit : 1 - Xen has no reference to the buffer and lttd-xen is the last process to unmap the buffers Decrement refcount Free them 2 - Xen and potentially many lttd-xen processes could map the buffers Decrement a reference count. Only free when the last lttd-xen process unmaps the buffer. > Actually I think we can support either way, although the former will work > right now and the latter will need a bit of extra support added into Xen. > I see your idea : the other way around would be to have lttctl-xen return an error if the buffers are actually mapped. It would however require some changes to the buffer scheme, as I support multiple start/stop tracing while keeping the same buffers and the same lttd-xen daemon. I would have to create a new ltt sub-hypercall to finalize the buffers, which would make lttd-xen write them to disk and exit. Controlling tracing from within a guest kernel or within the hypervisor would start to be a tricky business, as you would have to explicitely keep track of lttd-xen presence before freeing the buffers. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68