Hi Ingo, Namhyung, >>> An alternate approach is mem_op BPF filter: >>> >>> perf record --filter "mem_op == load || mem_op == store" ... >>> >>> However, there are few issues with it: >>> o BPF filter is called after preparing entire perf sample. If the sample >>> does not satisfy the filtering criteria, all the efforts of preparing >>> perf sample gets wasted. >> >> Could we add an 'early' BPF callback point as well, to fast-discard >> samples? > > I guess that would require a new BPF program type than PERF_EVENT and > handle driver-specific details. Right. >>> o BPF filter requires root privilege. >> >> Could we add 'built-in', 'safe' BPF scripts that are specifically >> prepared for perf events filtering purposes, that can be toggled by >> non-root users as well? These could be toggled by tooling via sysfs or >> so, or even via the perf syscall if that turns out to be the better >> approach. > > We have BPF filter framework in the perf tools and it can be run as > normal user. But root user should load and pin the BPF program prior > to use like below. > > $ sudo perf record --setup-filter pin > > $ perf record -d -e ibs_op/swfilt/u --filter 'mem_op == load' ... Thanks Namhyung. Ingo, Do you feel the idea of perf specific 'safe' BPF script is still worth pursuing despite similar functionality is already provided by --setup-filter? Thanks, Ravi
