On 5/5/15 9:46 PM, Wang Nan wrote:
Hi Alexei Starovoitov,
Have you ever read this mail?
please don't top post.
all makes sense and your use case fits quite well into existing
bpf+kprobe model. I'm not sure why you're calling a 'problem'.
A problem of how to display that call stack from perf?
I would say it fits better as a sample than a trace.
If you dump it as a trace, it won't easy to decipher, whereas if you
treat it a sampling event, perf record/report facility will pick it up and
display nicely. Meaning that one sample == lock_page/unlock_page
latency > N. Then existing sample_callchain flag should work.
Quite well. Do we have an eBPF function like
static int (*bpf_perf_sample)(const char *fmt, int fmt_size, ...) =
BPF_FUNC_perf_sample
so we can use it in the program probed in the body of __unlock_page() like that:
...
if (latency > 0.5s)
bpf_perf_sample("page=%p, latency=%d", sizeof(...), page, latency);
No need for extra helper. There is already return value from
the program for this purpose.
From kernel/trace/bpf_trace.c:
* Return: BPF programs always return an integer which is interpreted by
* kprobe handler as:
* 0 - return from kprobe (event is filtered out)
* 1 - store kprobe event into ring buffer
in your case the program attached to unlock_page() can return 1
when it needs to store this event into ring buffer, so that perf can
process it. If I'm not mistaken, the sample_callchain flag cannot be
applied to kprobe events, but that's a general program (not
related to bpf) and can be addressed as such.
--
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/
