* 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
|
Home