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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).