From: Steven Rostedt <rostedt@goodmis.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Xen Devel <Xen-devel@lists.xensource.com>,
Ingo Molnar <mingo@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Subject: Re: [PATCH 09/15] xen/trace: add tlb flush tracepoints
Date: Thu, 23 Jun 2011 22:00:01 -0400 [thread overview]
Message-ID: <1308880801.531.54.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <4E03C510.5050801@goop.org>
On Thu, 2011-06-23 at 15:58 -0700, Jeremy Fitzhardinge wrote:
> > If you really need something like this, maybe I'll add a
> > DEFINE_EVENT_NOARGS() that will not require arguments and can eliminate
> > a lot of code that TRACE_EVENT() adds.
>
> If you like, but only if you think its worth the effort. The empty
> string thing is a bit of an ugly hack, but its not like it makes a mess
> everywhere.
The problem I have is not the ugliness, but more of the wasted code that
is generated to do nothing. The TRACE_EVENT() generates lots of helper
functions that are unique to handle different events. The fact that we
have no args is generating code that does a lot of nothing. Every
TRACE_EVENT() can create 5k of code/data. This is why I advocate the
DEFINE_TRACE_CLASS() and DEFINE_EVENT() because it reuses a lot of the
code.
If we had a NOARGS event that was just a marker, then we could eliminate
most of the helper functions for these kinds of trace points.
-- Steve
next prev parent reply other threads:[~2011-06-24 2:00 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-20 22:14 [PATCH 00/15] xen: use tracing to replace ad-hoc debug/stats stuff Jeremy Fitzhardinge
2011-06-20 22:14 ` [PATCH 01/15] trace/xen: add skeleton for Xen trace events Jeremy Fitzhardinge
2011-06-20 22:14 ` [PATCH 02/15] xen/multicalls: remove debugfs stats Jeremy Fitzhardinge
2011-06-20 22:14 ` [PATCH 03/15] xen/trace: set up tracepoint skeleton Jeremy Fitzhardinge
2011-06-20 22:15 ` [PATCH 04/15] xen/trace: add multicall tracing Jeremy Fitzhardinge
2011-06-21 13:52 ` Konrad Rzeszutek Wilk
2011-06-21 17:11 ` Jeremy Fitzhardinge
2011-06-21 17:21 ` Konrad Rzeszutek Wilk
2011-06-20 22:15 ` [PATCH 05/15] xen/trace: add mmu tracepoints Jeremy Fitzhardinge
2011-06-21 0:27 ` Steven Rostedt
2011-06-20 22:15 ` [PATCH 06/15] xen/trace: add ptpage alloc/release tracepoints Jeremy Fitzhardinge
2011-06-21 13:55 ` Konrad Rzeszutek Wilk
2011-06-20 22:15 ` [PATCH 07/15] xen/trace: add xen_pgd_(un)pin tracepoints Jeremy Fitzhardinge
2011-06-21 0:28 ` Steven Rostedt
2011-06-21 17:30 ` Jeremy Fitzhardinge
2011-06-20 22:15 ` [PATCH 08/15] xen/trace: add segment desc tracing Jeremy Fitzhardinge
2011-06-21 14:03 ` Konrad Rzeszutek Wilk
2011-06-21 17:14 ` Jeremy Fitzhardinge
2011-06-20 22:15 ` [PATCH 09/15] xen/trace: add tlb flush tracepoints Jeremy Fitzhardinge
2011-06-21 14:07 ` Konrad Rzeszutek Wilk
2011-06-23 19:52 ` Jeremy Fitzhardinge
2011-06-23 20:23 ` Steven Rostedt
2011-06-23 22:58 ` Jeremy Fitzhardinge
2011-06-24 2:00 ` Steven Rostedt [this message]
2011-06-20 22:15 ` [PATCH 10/15] xen/mmu: use extend_args for more mmuext updates Jeremy Fitzhardinge
2011-06-20 22:15 ` [PATCH 11/15] xen/mmu: tune pgtable alloc/release Jeremy Fitzhardinge
2011-06-20 22:15 ` [PATCH 12/15] xen/multicalls: disable MC_DEBUG Jeremy Fitzhardinge
2011-06-20 22:15 ` [PATCH 13/15] xen/multicalls: add unlikely around slowpath in __xen_mc_entry() Jeremy Fitzhardinge
2011-06-20 22:15 ` [PATCH 14/15] xen/multicall: special-case singleton hypercalls Jeremy Fitzhardinge
2011-06-20 22:15 ` [PATCH 15/15] xen/multicall: move *idx fields to start of mc_buffer Jeremy Fitzhardinge
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=1308880801.531.54.camel@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=Xen-devel@lists.xensource.com \
--cc=jeremy.fitzhardinge@citrix.com \
--cc=jeremy@goop.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.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
all inboxes | Powered by JetHome®