On 4/18/16 1:47 PM, Steven Rostedt wrote:
On Mon, 18 Apr 2016 12:51:43 -0700
Alexei Starovoitov wrote:
yeah, it could be added to ftrace as well, but it won't be as effective
as perf_trace, since the cost of trace_event_buffer_reserve() in
trace_event_raw_event_() handler is significantly hig
On Mon, 18 Apr 2016 12:51:43 -0700
Alexei Starovoitov wrote:
> yeah, it could be added to ftrace as well, but it won't be as effective
> as perf_trace, since the cost of trace_event_buffer_reserve() in
> trace_event_raw_event_() handler is significantly higher than
> perf_trace_buf_alloc() in p
On 4/18/16 9:13 AM, Steven Rostedt wrote:
On Mon, 4 Apr 2016 21:52:46 -0700
Alexei Starovoitov wrote:
Hi Steven, Peter,
last time we discussed bpf+tracepoints it was a year ago [1] and the reason
we didn't proceed with that approach was that bpf would make arguments
arg1, arg2 to trace_xx(arg
On Mon, 4 Apr 2016 21:52:46 -0700
Alexei Starovoitov wrote:
> Hi Steven, Peter,
>
> last time we discussed bpf+tracepoints it was a year ago [1] and the reason
> we didn't proceed with that approach was that bpf would make arguments
> arg1, arg2 to trace_xx(arg1, arg2) call to be exposed to bpf
Hi Steven, Peter,
last time we discussed bpf+tracepoints it was a year ago [1] and the reason
we didn't proceed with that approach was that bpf would make arguments
arg1, arg2 to trace_xx(arg1, arg2) call to be exposed to bpf program
and that was considered unnecessary extension of abi. Back then
