[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55147C19.5090302@gmail.com>
Date: Thu, 26 Mar 2015 15:37:29 -0600
From: David Ahern <dsahern@...il.com>
To: Don Zickus <dzickus@...hat.com>
CC: acme@...nel.org, linux-kernel@...r.kernel.org,
Joe Mario <jmario@...hat.com>, Jiri Olsa <jolsa@...hat.com>
Subject: Re: [PATCH v2] perf tool: Fix ppid for synthesized fork events
On 3/26/15 3:11 PM, Don Zickus wrote:
> Sorry for drawing this out. Originally the performance still seemed off.
> But as we split the patch up to see where the perf impact was, the problem
> seemed to have disappeared. So we are testing the original patch again.
>
> The only difference now is we were playing with the -BN option in perf based
> on your changelog, just because we never used it before. :-)
I was beyond surprised that you were measuring a 50% hit with the first
patch. As mentioned in a previous response it only adds the processing
of 3 additional lines to the already opened and read /proc/pid/status
file. So, when I wrote this second version I wanted to make sure we are
only measuring the impact of this change. The /proc/pid/status files are
read on startup of the record -- before any samples are taken.
The intent of '-e cpu-clock -F 1000 -- usleep 1' is to avoid any samples
since we don't care about them. Really the -a should be dropped as well
-- no need to open per-cpu events.
-B impacts processing done at the end of the run:
builin-record.c, __cmd_record():
if (!rec->no_buildid)
process_buildids(rec);
and -N says don't copying anything to ~/.debug. All together it tries to
focus the measurement to /proc walking.
>
> One last test without the -BN option and if that looks fine, then we have no
> objections. Again sorry for dragging this out. I will let you know
> tomorrow EST.
no problem; appreciate the heads up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists