On 7/1/15 10:52 PM, Wangnan (F) wrote:
I'd like to discuss with you about the correctness of our understanding. Do you have any strong reason to put BPF filters at such an early stage?
the obvious reason is performance. It is so much faster to run generated 'if (bpf_get_current_pid() != expected_pid) return' instead of going through __get_data_size, perf_trace_buf_prepare, store_trace_args, perf_trace_buf_submit->perf_tp_event_match->filter_match_preds. bpf is the fastest way to filter out things, so it should be first. I would argue that even for regular samples (cycle counts and so on), we should be using this tiny bpf prog to filter by pid. It's around 5 or so instructions that perf can always use instead of doing 'common_pid != expected_pid' > filter. Disturbance to the whole kernel will be much lower. Obviously there are no hooks for bpf programs in regular samples, but I think it's worth doing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
