From: David Ahern <dsahern@gmail.com>
To: Benjamin Moody <benjamin.moody@gmail.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: Bizarre results from perf event API
Date: Mon, 23 Feb 2015 18:21:35 -0700 [thread overview]
Message-ID: <54EBD21F.3030101@gmail.com> (raw)
In-Reply-To: <CAAk6P0X5N3pvEjaEy-v6mHy7+fg3pdLyeRYR2VGm2wuqPYeOZw@mail.gmail.com>
On 2/21/15 2:44 PM, Benjamin Moody wrote:
> Hi,
>
>> Trying using a program with established results. e.g., This is from
>> PeterZ years ago. On intel 'perf stat -e instructions a.out' should show
>> ~1 billion (a wee bit more, but clearly in the 1b range).
>
> That program itself gave the expected results, but it's a good
> suggestion. When I tried changing that program to also fork a bunch
> of child processes, I started getting similarly weird results to what
> I had seen before.
This is with the 1billion instructions sent earlier:
$ ./myperfstat ./1bi
Total instructions: 1000087491
$ perf stat -e instructions:u ./1bi
Performance counter stats for './1bi':
1,000,087,608 instructions:u
0.285943713 seconds time elapsed
Using the second version of this program:
#include <stdlib.h>
#include <stdio.h>
#include <time.h>
main ()
{
int i;
fork();
fork();
for (i = 0; i < 100000000; i++) {
asm("nop");
asm("nop");
asm("nop");
asm("nop");
asm("nop");
asm("nop");
asm("nop");
}
wait(NULL);
wait(NULL);
wait(NULL);
wait(NULL);
}
This one spawn child processes so you have
perf -> child -> gchild -> ggchild
|---> gchild
So it has the grandparent characteristics you are getting at.
$ ./myperfstat ./1bi4
Total instructions: 4000094342
$ perf stat -e instructions:u ./1bi4
Performance counter stats for './1bi4':
4,000,094,649 instructions:u
0.259537842 seconds time elapsed
Still seems to match up.
This is on:
$ uname -r
3.18.7-200.fc21.x86_64
>
> Looking more closely at the behavior of perf, I think the essential
> difference is that perf uses the *child* PID as argument to
> perf_event_open. When I tried changing my program to do the same, it
> seems to have fixed the problem. That is to say, where I used
> something like
And I did not modify the mystat.c program to do this:
>
> fd = perf_event_open(..., getpid(), ...);
> child = fork();
> if (child == 0) {
> execvp(...);
> }
>
> I needed to instead use
>
> pipe(pipefd);
> child = fork();
> if (child == 0) {
> read(pipefd[0], &x, 1);
> execvp(...);
> }
> fd = perf_event_open(..., child, ...);
> write(pipefd[1], &x, 1);
next prev parent reply other threads:[~2015-02-24 1:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-20 23:26 Bizarre results from perf event API Benjamin Moody
2015-02-21 0:39 ` David Ahern
2015-02-21 21:44 ` Benjamin Moody
2015-02-21 22:59 ` Vince Weaver
2015-02-22 20:12 ` Benjamin Moody
2015-02-22 20:37 ` Vince Weaver
2015-02-24 0:46 ` Benjamin Moody
2015-02-24 1:21 ` David Ahern [this message]
2015-02-27 21:41 ` Benjamin Moody
2015-02-23 20:44 ` Andi Kleen
2015-02-23 23:13 ` Benjamin Moody
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=54EBD21F.3030101@gmail.com \
--to=dsahern@gmail.com \
--cc=benjamin.moody@gmail.com \
--cc=linux-perf-users@vger.kernel.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.