From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Anton Blanchard <anton@samba.org>
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org, imunsie@au1.ibm.com,
rostedt@goodmis.org, amodra@gmail.com
Subject: Re: PowerPC ftrace function trace optimisation
Date: Thu, 29 Apr 2010 11:08:14 +1000 [thread overview]
Message-ID: <1272503294.24542.140.camel@pasglop> (raw)
In-Reply-To: <1272502967.24542.137.camel@pasglop>
On Thu, 2010-04-29 at 11:02 +1000, Benjamin Herrenschmidt wrote:
> > The option Alan added reduces the footprint to 3 instructions which can
> > be noped out completely. The rest of the function does not rely on the first
> > three instructions. No stack spill is forced either:
> >
> > # gcc -pg -mprofile-kernel
>
> >From a quick test it appears that this only works with -m64, not -m32.
> Alan is that correct ? Any chance you can fix that in future gcc
> versions ?
>
> Also should we implement support for both type of mcounts or just only
> allow enabling of ftrace with gcc's that support this ?
Also, Anton noticed :
> Cheers,
> Ben.
>
> > 0000000000000000 <.foo>:
> > 0: 7c 08 02 a6 mflr r0
> > 4: f8 01 00 10 std r0,16(r1)
The std is not useful here. We can do it inside mcount.
> > 8: 48 00 00 01 bl 8 <.foo+0x8> <--- call to mcount
And I noticed:
> > c: 7c 08 02 a6 mflr r0
I'm happy to guarantee that mcount does the above.
> > 10: f8 01 00 10 std r0,16(r1)
And maybe that one too.
However I understand if it's easier not to change the prolog codegen
(the 2 insn above) and just stick to adding a 2 or 3 instructions
boilerplate at the top.
Cheers,
Ben.
> > 14: f8 21 ff d1 stdu r1,-48(r1)
> > 18: e9 22 00 00 ld r9,0(r2)
> > 1c: e8 69 00 02 lwa r3,0(r9)
> > 20: 38 21 00 30 addi r1,r1,48
> > 24: e8 01 00 10 ld r0,16(r1)
> > 28: 7c 08 03 a6 mtlr r0
> > 2c: 4e 80 00 20 blr
> >
> >
> > This mean we could support ftrace function trace with very little overhead.
> >
> > In fact if we are careful when switching to the new mcount ABI and don't
> > rely on the store of r0, we could probably optimise this even further in a
> > future gcc and remove the store completely. mcount would be 2 instructions:
> >
> > mflr r0
> > bl 8 <.foo+0x8>
> >
> > Anton
>
next prev parent reply other threads:[~2010-04-29 1:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-29 0:51 PowerPC ftrace function trace optimisation Anton Blanchard
2010-04-29 1:02 ` Benjamin Herrenschmidt
2010-04-29 1:08 ` Benjamin Herrenschmidt [this message]
2010-04-29 1:22 ` Alan Modra
2010-04-29 1:55 ` Steven Rostedt
2010-04-29 2:10 ` Benjamin Herrenschmidt
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=1272503294.24542.140.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=amodra@gmail.com \
--cc=anton@samba.org \
--cc=imunsie@au1.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=rostedt@goodmis.org \
/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.