From: Jason Baron <jbaron@redhat.com>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: linux-kernel@vger.kernel.org, roland@redhat.com, rth@redhat.com,
mingo@elte.hu
Subject: Re: [PATCH 0/4] RFC: jump label - (tracepoint optimizations)
Date: Tue, 8 Sep 2009 16:48:54 -0400 [thread overview]
Message-ID: <20090908204853.GC2641@redhat.com> (raw)
In-Reply-To: <20090907154824.GA1085@Krystal>
On Mon, Sep 07, 2009 at 11:48:24AM -0400, Mathieu Desnoyers wrote:
> > ".pushsection __jump_table, \"a\" \n\t" \
> > _ASM_PTR "1b, %l[" #label "], %c0 \n\t" \
> > ".popsection \n\t" \
> > : : "i" (__sjstrtab_##tag) : : label)
> >
>
> Supporting multiple labels to create a real jump table would be a
> nice-to-have as future enhancement too. This could be called
> STATIC_JUMP_TABLE(). Actually, the STATIC_JUMP_IF could probably be
> implemented in terms of STATIC_JUMP_TABLE.
>
> > #else
> >
> > #define STATIC_JUMP_IF(tag, label, cond) \
> > if (unlikely(cond)) \
> > goto label;
> >
>
> Hrm, however, it's not clear to me how the STATIC_JUMP_TABLE() fallback
> would look like. In the case of STATIC_JUMP_IF, it's a simple if (),
> which makes support of compilers lacking static jump support easy. We
> could probably use a switch statement to replace the STATIC_JUMP_TABLE
> though.
>
right - if we have more labels passed into STATIC_JUMP_TABLE(), we can
probably do a case statement with a 'goto' to the correct label.
> > #endif /* !HAVE_STATIC_JUMP */
> >
> >
> > which can be used as:
> >
> > STATIC_JUMP_IF(trace, trace_label, jump_enabled);
> > printk("not doing tracing\n");
> > if (0) {
> > trace_label:
> > printk("doing tracing: %d\n", file);
> > }
> >
>
> Hrm. Is there any way to make this a bit prettier ? Given modifications
> are made to gcc anyway...
>
> Maybe:
>
> static_jump_if (trace, jump_enabled) {
> ...
>
> } else {
> ...
> }
>
> And for the jump table:
>
> static_jump_table (trace, jump_select) {
> case 0: ...
> break;
> case 1: ...
> break;
> default:
> ...
> }
>
hmmm...yes, I agree it would be nice if the code looked a little prettier.
However, short of additional gcc changes i'm not sure how to do that.
perhaps, somebody has some better ideas? Note also, that the
'STATIC_JUMP_IF()' as defined implements both:
if () { }
and:
if () { } else { }
I'm not sure the code is that hideous as proposed. However, I definitely
would be interested it other opinions? Also, in this case note that the
STATIC_JUMP_IF() is only added to 1 place in the code, and doesn't
affect any of the normal tracepoint API.
>
> > ---------------------------------------
> >
> > Thus, if 'HAVE_STATIC_JUMP' is defined (which will depend ultimately on the
> > existence of 'asm goto' in the compiler version), we simply have a no-op
> > followed by a jump around the dormant (disabled) tracing code.
>
> Hrm, why don't we collapse that into a single 5-bytes jump instruction
> instead ?
that might be nice, but would require more complex compiler support. I'm
not sure if the extra complexity is worth the 2-byte i-cache savings?
That is, I think we're getting the majority of the savings with the
proposed solution.
thanks,
-Jason
prev parent reply other threads:[~2009-09-08 20:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-03 20:25 [PATCH 0/4] RFC: jump label - (tracepoint optimizations) Jason Baron
2009-09-03 20:25 ` [PATCH 1/4] RFC: basic jump label implementation Jason Baron
2009-09-03 20:25 ` [PATCH 2/4] RFC: jump label example usage Jason Baron
2009-09-03 20:26 ` [PATCH 3/4] RFC: implement tracepoints on top of jump patching Jason Baron
2009-09-03 20:26 ` [PATCH 4/4] RFC: performance testing harness Jason Baron
2009-09-03 20:45 ` [PATCH 0/4] RFC: jump label - (tracepoint optimizations) Daniel Walker
2009-09-03 21:01 ` Ingo Molnar
2009-09-03 21:11 ` Roland McGrath
2009-09-07 15:48 ` Mathieu Desnoyers
2009-09-07 17:06 ` Mathieu Desnoyers
2009-09-10 21:15 ` Steven Rostedt
2009-09-08 20:48 ` Jason Baron [this message]
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=20090908204853.GC2641@redhat.com \
--to=jbaron@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@elte.hu \
--cc=roland@redhat.com \
--cc=rth@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 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.