On Wed, Jan 21, 2015 at 5:56 PM, Steven Rostedt wrote:
> On Wed, 21 Jan 2015 17:49:08 -0800
> Alexei Starovoitov wrote:
>
>
>> > This also makes it keeping events in the soft-disabled state.
>>
>> I was never able to figure out the use case for soft-disabled state.
>> Probably historical before
On Wed, 21 Jan 2015 17:49:08 -0800
Alexei Starovoitov wrote:
> > This also makes it keeping events in the soft-disabled state.
>
> I was never able to figure out the use case for soft-disabled state.
> Probably historical before static_key was done.
No, it's not historical at all. The
On Wed, Jan 21, 2015 at 5:03 PM, Namhyung Kim wrote:
>
> AFAIK a trigger can be fired before allocating a ring buffer if it
> doesn't use the event record (i.e. has filter) or ->post_trigger bit
> set (stacktrace). Please see ftrace_trigger_soft_disabled().
yes, but such trigger has no
Hi Alexei,
On Fri, Jan 16, 2015 at 10:57:15AM -0800, Alexei Starovoitov wrote:
> On Fri, Jan 16, 2015 at 7:02 AM, Steven Rostedt wrote:
> > One last thing. If the ebpf is used for anything but filtering, it
> > should go into the trigger file. The filtering is only a way to say if
> > the event
Hi Alexei,
On Fri, Jan 16, 2015 at 10:57:15AM -0800, Alexei Starovoitov wrote:
On Fri, Jan 16, 2015 at 7:02 AM, Steven Rostedt rost...@goodmis.org wrote:
One last thing. If the ebpf is used for anything but filtering, it
should go into the trigger file. The filtering is only a way to say if
On Wed, Jan 21, 2015 at 5:03 PM, Namhyung Kim namhy...@kernel.org wrote:
AFAIK a trigger can be fired before allocating a ring buffer if it
doesn't use the event record (i.e. has filter) or -post_trigger bit
set (stacktrace). Please see ftrace_trigger_soft_disabled().
yes, but such trigger
On Wed, Jan 21, 2015 at 5:56 PM, Steven Rostedt rost...@goodmis.org wrote:
On Wed, 21 Jan 2015 17:49:08 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
This also makes it keeping events in the soft-disabled state.
I was never able to figure out the use case for soft-disabled state.
On Wed, 21 Jan 2015 17:49:08 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
This also makes it keeping events in the soft-disabled state.
I was never able to figure out the use case for soft-disabled state.
Probably historical before static_key was done.
No, it's not historical at all.
On Tue, Jan 20, 2015 at 3:57 AM, Masami Hiramatsu
wrote:
>
> Ok, BTW, would you think is it possible to use a reusable small scratchpad
> memory for passing arguments? (just a thought)
sure. doable, but what's the use case?
>> It's not usable for high frequency events which
>> need this
(2015/01/20 12:55), Alexei Starovoitov wrote:
> On Mon, Jan 19, 2015 at 6:58 PM, Masami Hiramatsu
> wrote:
>>>
>>> it's done already... one can do the same skb->dev->name logic
>>> in kprobe attached program... so from bpf program point of view,
>>> tracepoints and kprobes feature-wise are
(2015/01/20 12:55), Alexei Starovoitov wrote:
On Mon, Jan 19, 2015 at 6:58 PM, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
it's done already... one can do the same skb-dev-name logic
in kprobe attached program... so from bpf program point of view,
tracepoints and kprobes
On Tue, Jan 20, 2015 at 3:57 AM, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
Ok, BTW, would you think is it possible to use a reusable small scratchpad
memory for passing arguments? (just a thought)
sure. doable, but what's the use case?
It's not usable for high frequency events
On Mon, Jan 19, 2015 at 6:58 PM, Masami Hiramatsu
wrote:
>>
>> it's done already... one can do the same skb->dev->name logic
>> in kprobe attached program... so from bpf program point of view,
>> tracepoints and kprobes feature-wise are exactly the same.
>> Only input is different.
>
> No, I
(2015/01/20 5:48), Alexei Starovoitov wrote:
> On Mon, Jan 19, 2015 at 1:52 AM, Masami Hiramatsu
> wrote:
>> If we can write the script as
>>
>> int bpf_prog4(s64 write_size)
>> {
>>...
>> }
>>
>> This will be much easier to play with.
>
> yes. that's the intent for user space to do.
>
>>>
On Mon, Jan 19, 2015 at 1:52 AM, Masami Hiramatsu
wrote:
> If we can write the script as
>
> int bpf_prog4(s64 write_size)
> {
>...
> }
>
> This will be much easier to play with.
yes. that's the intent for user space to do.
>> The example of this arbitrary pointer walking is
(2015/01/16 13:16), Alexei Starovoitov wrote:
> Hi Ingo, Steven,
>
> This patch set is based on tip/master.
> It adds ability to attach eBPF programs to tracepoints, syscalls and kprobes.
>
> Mechanism of attaching:
> - load program via bpf() syscall and receive program_fd
> - event_fd =
On Mon, Jan 19, 2015 at 6:58 PM, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
it's done already... one can do the same skb-dev-name logic
in kprobe attached program... so from bpf program point of view,
tracepoints and kprobes feature-wise are exactly the same.
Only input is
(2015/01/20 5:48), Alexei Starovoitov wrote:
On Mon, Jan 19, 2015 at 1:52 AM, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
If we can write the script as
int bpf_prog4(s64 write_size)
{
...
}
This will be much easier to play with.
yes. that's the intent for user space to
(2015/01/16 13:16), Alexei Starovoitov wrote:
Hi Ingo, Steven,
This patch set is based on tip/master.
It adds ability to attach eBPF programs to tracepoints, syscalls and kprobes.
Mechanism of attaching:
- load program via bpf() syscall and receive program_fd
- event_fd =
On Mon, Jan 19, 2015 at 1:52 AM, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
If we can write the script as
int bpf_prog4(s64 write_size)
{
...
}
This will be much easier to play with.
yes. that's the intent for user space to do.
The example of this arbitrary pointer
On Fri, Jan 16, 2015 at 7:02 AM, Steven Rostedt wrote:
> On Thu, 15 Jan 2015 20:16:01 -0800
> Alexei Starovoitov wrote:
>
>> Hi Ingo, Steven,
>>
>> This patch set is based on tip/master.
>
> Note, the tracing code isn't maintained in tip/master, but perf code is.
I know. I can rebase against
On Thu, 15 Jan 2015 20:16:01 -0800
Alexei Starovoitov wrote:
> Hi Ingo, Steven,
>
> This patch set is based on tip/master.
Note, the tracing code isn't maintained in tip/master, but perf code is.
Using the latest 3.19-rc is probably sufficient for now.
Do you have a git repo somewhere that I
On Fri, Jan 16, 2015 at 7:02 AM, Steven Rostedt rost...@goodmis.org wrote:
On Thu, 15 Jan 2015 20:16:01 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
Hi Ingo, Steven,
This patch set is based on tip/master.
Note, the tracing code isn't maintained in tip/master, but perf code is.
I
On Thu, 15 Jan 2015 20:16:01 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
Hi Ingo, Steven,
This patch set is based on tip/master.
Note, the tracing code isn't maintained in tip/master, but perf code is.
Using the latest 3.19-rc is probably sufficient for now.
Do you have a git repo
Hi Ingo, Steven,
This patch set is based on tip/master.
It adds ability to attach eBPF programs to tracepoints, syscalls and kprobes.
Mechanism of attaching:
- load program via bpf() syscall and receive program_fd
- event_fd = open("/sys/kernel/debug/tracing/events/.../filter")
- write 'bpf-123'
Hi Ingo, Steven,
This patch set is based on tip/master.
It adds ability to attach eBPF programs to tracepoints, syscalls and kprobes.
Mechanism of attaching:
- load program via bpf() syscall and receive program_fd
- event_fd = open(/sys/kernel/debug/tracing/events/.../filter)
- write 'bpf-123'
26 matches
Mail list logo
