On Fri, 2011-04-08 at 13:02 -0400, Steven Rostedt wrote: > On Fri, 2011-04-08 at 16:07 +0200, Peter Zijlstra wrote: > > > > As you said perf has a lot of overhead due to data that it saves per > > > event. > > > > Someday you should actually read the perf code before you say something. > > I have looked at the code although not as much recently, but I do plan > on looking at it again in much more detail. But you are correct that I > did not make this comment on the code itself, but on looking at the > data: > 1051776/8766 = 119 > 2957312/38268 = 77 > > As you stated, I need to look more into the perf code (which I plan on > doing), but it seems that perf adds 42 bytes more per event. Perhaps > this is something we can fix. Aside from the 8 byte header everything else is configurable with PERF_SAMPLE_flags and probably has some overlap with stuff we also have in the tracepoint data we then get through PERF_SAMPLE_RAW > I'd love to make both perf and ftrace be > able to limit its header. There's no reason to record the pid for every > event if we don't need to. As well as the preempt count and interrupt > status. But these are legacy from the latency tracer code from -rt. Right. > I think there's a lot of work that we can do make tracing in perf more > compatible with the tracing features of ftrace. I did say the ugly word > "roadmap" but perhaps it's just direction that we need. I feel we are > all a bunch of cooks with their own taste, and we don't all like the > spices used by each other. Partly yeah, but there's also real functional differences, the last time I profiled perf with perf (yay for recursion) we spend a lot of time in conditionals. Due to the fact that perf is mainly sampling based (and tracing being samples with period==1) and all that output configurability there's a true forest of if statements to pass through and I'm fairly sure we totally trash the branch predictor on that. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
