From: Steven Rostedt <rostedt@goodmis.org>
To: Will Hawkins <whh8b@virginia.edu>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Ftrace vs perf user page fault statistics differences
Date: Mon, 19 Jun 2017 14:52:45 -0400 [thread overview]
Message-ID: <20170619145245.6966c134@gandalf.local.home> (raw)
In-Reply-To: <CAE+MWFuzG-4e_goiY_cBEZkrid4PWeSGqLKbzer_cfcK2Xyc2Q@mail.gmail.com>
On Mon, 19 Jun 2017 13:13:27 -0400
Will Hawkins <whh8b@virginia.edu> wrote:
> On Wed, Jun 14, 2017 at 4:01 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Wed, 14 Jun 2017 13:47:17 -0400
> > Will Hawkins <whh8b@virginia.edu> wrote:
> >
> >
> >> > That's how trace-cmd parses it.
> >>
> >> In the kernel version that I am running (again, pretty old) I do not
> >> have this file. I do, however, have
> >
> > It may be due to the kernel version. It gets the functions
> > from /proc/kallsyms. That could have have an issue. Although, I have
> > this too:
> >
> > # grep per_cpu_start /proc/kallsyms
> > 0000000000000000 A __per_cpu_start
>
> Here's my result of a similar command:
>
> # cat /proc/kallsyms | grep per_cpu_start
> 0000000000000000 D __per_cpu_start
Right, that it doesn't have the latest code to say to ignore it in your
kernel.
>
> There's only the difference between (what I think is) the flag value
> there in the second column.
>
> >
> > But I don't see it being converted in my report.
> >
> > Hmm, it's not saved. Interesting:
> >
> > trace-cmd report -f
> >
> > to see the list of saved functions. I need to figure out why it does
> > for you, but not for me.
>
> sudo ./trace-cmd report -f | grep per_cpu_start
> 0000000000000000 __per_cpu_start
Yep, it took it. It only saves the address an the name.
> > Ah, I bet it's a change in the kernel. A recent update to trace-cmd was
> > to ignore functions in kallsyms of type "A" (which you can see is what
> > I have above).
>
> And my output (above) seems to show that mine shows the per_cpu_start
> as a D instead of an A. Perhaps that is why we are seeing differences
> in our report? It's still curious that it would match 0x000..0 with
> something that is clearly, well, not 0x00...0.
Because function ips are seldom at the start of the function (well,
other than fentry code), it grabs the first function with the address
before the ip. Which would be 0x0000.
>
> Let me know if there is a spot in the code where it decides whether to
> symbolize. Or, I can work backward from the recent change you
> mentioned above to find that spot if you will tell me the hash of that
> commit.
If you run with trace-cmd report -O offset, you should see the offset
off of functions. Not sure it works with function graph tracer, but
should at least work with function tracing.
-- Steve
next prev parent reply other threads:[~2017-06-19 18:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-12 20:08 Will Hawkins
[not found] ` <CAE+MWFuvAtGc0boe3arhnyoVpCpJBOsBTpk8W7Lh6r5PFE-Hmg@mail.gmail.com>
2017-06-13 1:20 ` Steven Rostedt
2017-06-13 2:05 ` Will Hawkins
2017-06-13 13:06 ` Steven Rostedt
2017-06-13 18:02 ` Will Hawkins
2017-06-13 20:04 ` Steven Rostedt
2017-06-14 1:27 ` Will Hawkins
2017-06-14 2:13 ` Steven Rostedt
2017-06-14 17:47 ` Will Hawkins
2017-06-14 20:01 ` Steven Rostedt
2017-06-19 17:13 ` Will Hawkins
2017-06-19 18:52 ` Steven Rostedt [this message]
2017-06-14 3:04 ` Namhyung Kim
2017-06-14 17:30 ` Will Hawkins
2017-06-14 17:43 ` Steven Rostedt
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=20170619145245.6966c134@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=linux-kernel@vger.kernel.org \
--cc=whh8b@virginia.edu \
/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®