Re: [PATCH v2] perf tool: Fix ppid for synthesized fork events

[David Ahern]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/