Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754327Ab1DILJA (ORCPT ); Sat, 9 Apr 2011 07:09:00 -0400 Received: from bombadil.infradead.org ([18.85.46.34]:59381 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754077Ab1DILI7 convert rfc822-to-8bit (ORCPT ); Sat, 9 Apr 2011 07:08:59 -0400 Subject: Re: [RFC] tracing: Adding cgroup aware tracing functionality From: Peter Zijlstra To: Steven Rostedt Cc: Frederic Weisbecker , David Sharp , Vaibhav Nagarnaik , Paul Menage , Li Zefan , Stephane Eranian , Andrew Morton , Michael Rubin , Ken Chen , linux-kernel@vger.kernel.org, containers@lists.linux-foundation.org, Thomas Gleixner , Ingo Molnar , Arnaldo Carvalho de Melo In-Reply-To: <1302282130.21026.45.camel@frodo> References: <20110407013349.GH1867@nowhere> <20110407120608.GB1798@nowhere> <20110407213208.GE1798@nowhere> <20110408002812.GG1798@nowhere> <1302248268.21026.18.camel@frodo> <1302271670.9086.154.camel@twins> <1302282130.21026.45.camel@frodo> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Sat, 09 Apr 2011 13:08:35 +0200 Message-ID: <1302347315.9086.1246.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2186 Lines: 51 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/