All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lluís Vilanova" <vilanova@ac.upc.edu>
To: "Denis V. Lunev" <den@openvz.org>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	armbru@redhat.com, qemu-devel@nongnu.org, dgilbert@redhat.com
Subject: Re: [Qemu-devel] [PATCH 0/2] improve tracing
Date: Mon, 24 Jul 2017 17:43:05 +0300	[thread overview]
Message-ID: <87y3rdopza.fsf@frigg.lan> (raw)
In-Reply-To: <2c20cdf2-9e70-89ef-f323-d7ef77f70b29@openvz.org> (Denis V. Lunev's message of "Mon, 24 Jul 2017 15:17:16 +0300")

Denis V Lunev writes:

> On 07/24/2017 02:34 PM, Stefan Hajnoczi wrote:
>> On Fri, Jul 21, 2017 at 05:31:47PM +0300, Vladimir Sementsov-Ogievskiy wrote:
>>> Current trace system have a drawback: parameters of trace functions
>>> are calculated even if corresponding tracepoint is disabled. Also, it
>>> looks like trace function are not actually inlined by compiler (at
>>> least for me).
>>> 
>>> Here is a fix proposal: move from function call to macros. Patch 02
>>> is an example, of how to reduce extra calculations with help of
>>> patch 01.
>>> 
>>> Vladimir Sementsov-Ogievskiy (2):
>>> trace: do not calculate arguments for disabled trace-points
>>> monitor: improve tracing in handle_qmp_command
>> Please use the TRACE_FOO_ENABLED macro instead of putting computation
>> inside the trace event arguments.  This makes the code cleaner and
>> easier to read.
> At our opinion this ENABLED is compile time check while the option
> could be tuned in runtime. Thus normally it would normally be
> enabled while the trace is silent.

> So, under load, we will have extra allocation, copying the command buffer,
> freeing memory without actual trace. In order to fix that we should
> do something like

> if (trace_event_get_state(TRACE_HANDLE_QMP_COMMAND)) {
>    req_json = qobject_to_json(req);
>    trace_handle_qmp_command(mon, req_json);
>    QDECREF(req_json);
> }

> which is possible, but at our (me + Vova) opinion is ugly.
> That is why we are proposing to switch to macro, which
> will not require such tweaking.

> Arguments will be only evaluated when necessary and we
> will not have side-effects if the tracepoint is compile time
> enabled and run-time disabled.

> Though if the code above is acceptable, we can send the
> patch with it. No problem.

I completely get your point, but:

* I'm not sure it will have much of a performance impact.
* It is not obvious what's going to happen just by looking at the code of the
  calling site.

I prefer to minimize the use of macros, even if that makes a few trace event
calls to be a bit more verbose, as in your example above. Also, I quite dislike
the new style you propose:

  trace_handle_qmp_command(mon,
                           qstring_get_str(req_json = qobject_to_json(req)));
  QDECREF(req_json);


Cheers,
  Lluis

  reply	other threads:[~2017-07-24 14:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-21 14:31 [Qemu-devel] [PATCH 0/2] improve tracing Vladimir Sementsov-Ogievskiy
2017-07-21 14:31 ` [Qemu-devel] [PATCH 1/2] trace: do not calculate arguments for disabled trace-points Vladimir Sementsov-Ogievskiy
2017-07-21 14:31 ` [Qemu-devel] [PATCH 2/2] monitor: improve tracing in handle_qmp_command Vladimir Sementsov-Ogievskiy
2017-07-24 11:39   ` Stefan Hajnoczi
2017-07-21 17:04 ` [Qemu-devel] [PATCH 0/2] improve tracing Lluís Vilanova
2017-07-24  8:55   ` Vladimir Sementsov-Ogievskiy
2017-07-24 11:07     ` Lluís Vilanova
2017-07-24 11:16       ` Denis V. Lunev
2017-07-24 11:32   ` Stefan Hajnoczi
2017-07-24 11:34 ` Stefan Hajnoczi
2017-07-24 12:17   ` Denis V. Lunev
2017-07-24 14:43     ` Lluís Vilanova [this message]
2017-07-24 14:55       ` Denis V. Lunev
2017-07-24 16:32         ` Lluís Vilanova
2017-07-25 13:52           ` Stefan Hajnoczi
2017-07-24 16:24     ` Philippe Mathieu-Daudé

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=87y3rdopza.fsf@frigg.lan \
    --to=vilanova@ac.upc.edu \
    --cc=armbru@redhat.com \
    --cc=den@openvz.org \
    --cc=dgilbert@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vsementsov@virtuozzo.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.