All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: Keir Fraser <keir@xensource.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: LTTng-Xen Buffer shared between the hypervisor and a dom0 process
Date: Fri, 9 Mar 2007 22:02:30 -0500	[thread overview]
Message-ID: <20070310030230.GC9323@Krystal> (raw)
In-Reply-To: <C216D539.B1D1%keir@xensource.com>

* Keir Fraser (keir@xensource.com) wrote:
> On 8/3/07 19:30, "Mathieu Desnoyers" <compudj@krystal.dyndns.org> 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

  reply	other threads:[~2007-03-10  3:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-07 19:24 LTTng-Xen Buffer shared between the hypervisor and a dom0 process Mathieu Desnoyers
2007-03-08  7:51 ` Keir Fraser
2007-03-08  9:26   ` Mathieu Desnoyers
2007-03-08 10:02     ` Keir Fraser
2007-03-08 19:30       ` Mathieu Desnoyers
2007-03-09  9:11         ` Keir Fraser
2007-03-10  3:02           ` Mathieu Desnoyers [this message]
2007-03-10 17:18             ` Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070310030230.GC9323@Krystal \
    --to=compudj@krystal.dyndns.org \
    --cc=keir@xensource.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.