[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z04qmNnt86zcGE5Q@google.com>
Date: Mon, 2 Dec 2024 13:46:00 -0800
From: Namhyung Kim <namhyung@...nel.org>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Yang Jihong <yangjihong@...edance.com>, peterz@...radead.org,
mingo@...hat.com, mark.rutland@....com,
alexander.shishkin@...ux.intel.com, jolsa@...nel.org,
irogers@...gle.com, adrian.hunter@...el.com,
kan.liang@...ux.intel.com, james.clark@....com,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 00/12] perf record: Add event action support
Hello,
On Thu, Nov 28, 2024 at 05:14:53PM -0300, Arnaldo Carvalho de Melo wrote:
> On Thu, Nov 28, 2024 at 09:35:41PM +0800, Yang Jihong wrote:
> > In perf-record, when an event is triggered, default behavior is to
> > save sample data to perf.data. Sometimes, we may just want to do
> > some lightweight actions, such as printing a log.
>
> > Based on this requirement, add the --action option to the event to
> > specify the behavior when the event occurs.
>
> 'perf record' is centered on saving data to disk without processing
> events, while it has sideband events for some needs, like processing BPF
> related events (PERF_RECORD_BPF_EVENT to catch PERF_BPF_EVENT_PROG_LOAD
> and UNLOAD), doing things in a "live" way as your patchkit does seems
> more appropriate to do in 'perf trace' :-)
Agreed, 'perf trace' looks like a better place as you seem to target
tracepoint events mostly.
Thanks,
Namhyung
Powered by blists - more mailing lists