[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200526215415.GH2483@worktop.programming.kicks-ass.net>
Date: Tue, 26 May 2020 23:54:15 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Song Liu <songliubraving@...com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
Kernel Team <Kernel-team@...com>,
Ingo Molnar <mingo@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Masami Hiramatsu <mhiramat@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
Alexey Budankov <alexey.budankov@...ux.intel.com>
Subject: Re: [RFC] perf/core: allow ftrace for functions in
kernel/event/core.c
On Tue, May 26, 2020 at 09:46:29PM +0000, Song Liu wrote:
>
>
> > On May 26, 2020, at 2:39 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > On Tue, May 26, 2020 at 02:28:26PM -0700, Song Liu wrote:
> >> It is useful to trace functions in kernel/event/core.c. Allow ftrace for
> >> them by removing $(CC_FLAGS_FTRACE) from Makefile.
> >
> > Did you try using the ftrace event with perf with this on?
>
> I have tried a few things, like
>
> perf stat -e probe:perf_read -I 1000
> perf record -e probe:__x64_sys_perf_event_open -aR
>
> They all work fine.
>
> Do you have some tricky functions that we should double check?
I've no idea what probe: does. iirc there's something like
ftrace:function that is like regular function tracing.
At some point using that made the kernel really sick due to recursion
between ftrace and perf. Quite possibly that's been fixed, dunno.
Powered by blists - more mailing lists