[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZBBc5SQK2OhIGtGy@kernel.org>
Date: Tue, 14 Mar 2023 08:39:17 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Ravi Bangoria <ravi.bangoria@....com>
Cc: Namhyung Kim <namhyung@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Andi Kleen <ak@...ux.intel.com>,
Kan Liang <kan.liang@...ux.intel.com>,
Song Liu <song@...nel.org>,
Stephane Eranian <eranian@...gle.com>,
Leo Yan <leo.yan@...aro.org>,
James Clark <james.clark@....com>, Hao Luo <haoluo@...gle.com>,
LKML <linux-kernel@...r.kernel.org>,
linux-perf-users@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [RFC/PATCHSET 0/9] perf record: Implement BPF sample filter (v4)
Em Fri, Mar 10, 2023 at 12:04:03PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Mar 10, 2023 at 03:28:03PM +0530, Ravi Bangoria escreveu:
> > > It requires samples satisfy all the filter expressions otherwise it'd
> > > drop the sample. IOW filter expressions are connected with logical AND
> > > operations unless they used "||" explicitly. So if user has something
> > > like 'A, B || C, D', then BOTH A and D should be true AND either B or C
> > > also needs to be true.
> > >
> > > Essentially the BPF filter expression is:
> > >
> > > <term> <operator> <value> (("," | "||") <term> <operator> <value>)*
> > >
> > > The <term> can be one of:
> > > ip, id, tid, pid, cpu, time, addr, period, txn, weight, phys_addr,
> > > code_pgsz, data_pgsz, weight1, weight2, weight3, ins_lat, retire_lat,
> > > p_stage_cyc, mem_op, mem_lvl, mem_snoop, mem_remote, mem_lock,
> > > mem_dtlb, mem_blk, mem_hops
> > >
> > > The <operator> can be one of:
> > > ==, !=, >, >=, <, <=, &
> > >
> > > The <value> can be one of:
> > > <number> (for any term)
> > > na, load, store, pfetch, exec (for mem_op)
> > > l1, l2, l3, l4, cxl, io, any_cache, lfb, ram, pmem (for mem_lvl)
> > > na, none, hit, miss, hitm, fwd, peer (for mem_snoop)
> > > remote (for mem_remote)
> > > na, locked (for mem_locked)
> > > na, l1_hit, l1_miss, l2_hit, l2_miss, any_hit, any_miss, walk, fault (for mem_dtlb)
> > > na, by_data, by_addr (for mem_blk)
> > > hops0, hops1, hops2, hops3 (for mem_hops)
> >
> > I think this and few examples should be added in perf-record man page.
>
> Agreed, and even mentioning cases where it overcome problems like the
> filtering you mentioned for AMD systems.
So, what do you think is best? Wait for v5 or apply v4 and then add
documentation and other touches as followup patches?
- Arnaldo
Powered by blists - more mailing lists