Messages in this thread | | | Date | Fri, 27 Mar 2015 08:03:28 -0600 | From | David Ahern <> | Subject | Re: [PATCH v2] perf tool: Fix ppid for synthesized fork events |
| |
On 3/27/15 7:10 AM, Don Zickus wrote: > I talked with Joe on my way out the door yesterday and he confirmed, just > removing -BN from our test showed a performance hit with your patch. With > the -BN option, there is no performance hit and we are perfectly fine with > your patch. > > So, I guess I am confused how the -BN and your patch could change behaviour.
I am too. This change has nothing to do with buildid's and scanning the buildid code setting the ppid correctly should not cause any extra work.
Arnaldo: any thoughts?
> > Just to re-iterate what we did, Joe kicked off a specJBB run and he did 20 > captures of two runs (one with the unpatched binary and one with a pached > binary). > > for i in {1..20} > do > time perf.unpatched mem record -a -e cpu/mem-loads,ldlat=50/pp -e cpu/mem-stores/pp sleep 10 > time perf.patched mem record -a -e cpu/mem-loads,ldlat=50/pp -e cpu/mem-stores/pp sleep 10 > done > > then we repeat the above test but with -BN in both runs. We compare the > log sizes to make sure they are similar for the random snapshots and compare > the times. With the -BN option, the times are generally within +/- 0.5 > seconds of each. Without the -BN option the patched perf binary is > generally +20-40 seconds slower. > > > > However, based on your description above about what the -BN option does, I > am scratching my head about our results. Thoughts?
Try this: perf record -o unpatched.data -g -- perf.unpatched mem record -a -e cpu/mem-loads,ldlat=50/pp -e cpu/mem-stores/pp sleep 10
perf record -o patched.data -g -- perf.patched mem record -a -e cpu/mem-loads,ldlat=50/pp -e cpu/mem-stores/pp sleep 10
And then compare the reports for each.
David
| |