From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751615AbbKYRMs (ORCPT ); Wed, 25 Nov 2015 12:12:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43639 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751215AbbKYRMr (ORCPT ); Wed, 25 Nov 2015 12:12:47 -0500 Date: Wed, 25 Nov 2015 18:12:43 +0100 From: Jiri Olsa To: Steven Rostedt Cc: Jiri Olsa , lkml , David Ahern , Ingo Molnar , Namhyung Kim , Peter Zijlstra , Arnaldo Carvalho de Melo Subject: Re: [PATCH 1/2] ftrace: Add separate handler for ftrace:function event Message-ID: <20151125171243.GA2214@krava.brq.redhat.com> References: <1448466333-28102-1-git-send-email-jolsa@kernel.org> <20151125111956.7d53da99@gandalf.local.home> <20151125165057.GA30914@krava.brq.redhat.com> <20151125120257.17e53cab@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151125120257.17e53cab@gandalf.local.home> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 25, 2015 at 12:02:57PM -0500, Steven Rostedt wrote: > On Wed, 25 Nov 2015 17:50:57 +0100 > Jiri Olsa wrote: > > > > This seems redundant. I never understood the control_ops that perf uses > > > in the function tracing infrastructure. Why can't you just register the > > > event->ops and have that ops set the filtering? Then the ftrace > > > infrastructure will only call that event handler for the functions its > > > filtered on. Then you don't need to do it again. Right now ftrace > > > already does that with the generic "control_ops" that perf uses, but > > > now you are doing it again. Seems rather pointless. > > > > well thats exactly what we are doing.. but as all ops > > share single callback we need to find the proper event > > this callback was triggered for > > The ftrace_ops has a "private" field for the user to set. Could you > make that point back to the event that allocated the ftrace_ops? > Then the callback function could easily get the event that matches the > ftrace_ops. aaah did not see this one ;-) that will do.. nice > > > > > currently we use tracepoint callback (perf_tp_event) > > where the proper event is found based on the event->filter > > > > however this is not the case for ftrace:function because > > filter will not change the event->filter, but the ops filter > > Yeah, I'm trying to figure out the paths here. I would love to remove > the control_ops as that complicates the function tracing code a bit > more than I would like it to be. perf is using the control interface to enable and disable function tracing any time the process (and its events) is scheduled in/out sched_in(event) -> ftrace_function_local_enable(&event->ftrace_ops) sched_out(event) -> ftrace_function_local_disable(&event->ftrace_ops) > > I just crashed function tracing by function tracing perf doing function > tracing :-) I'm currently debugging that (and adding more code to help > debug things like this). ;-) jirka