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

Re: [Xen-devel] LTTng-Xen Buffer shared between the hypervisor and a dom0 process



* Keir Fraser (keir@xxxxxxxxxxxxx) wrote:
> On 8/3/07 19:30, "Mathieu Desnoyers" <compudj@xxxxxxxxxxxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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