(Note that I also agree with Linus's opinion that this is
like a debugger, since I already did it in perf-probe :))
On Sun, 4 Feb 2018 11:39:39 -0800
Linus Torvalds wrote:
> (Obviously it's not entirely black-and-white, but I do think there is
> a pretty big difference between the two groups. A
On Mon, 5 Feb 2018 11:49:31 +0100
Daniel Bristot de Oliveira wrote:
> Isn't this the case of calling tracing functions before calling:
>
> rcu_irq_enter();
Yes, I'm actually aware of this. I just forgot to deal with it during
development.
Thanks, for reporting.
-- Steve
On Mon, 5 Feb 2018 11:09:31 +0100
Peter Zijlstra wrote:
> As a run-around, Steve then suggested to decouple the trace-hook from
> the actual trace-event. Let the scheduler only provide the hook, nothing
> else. And then allow users to create their own events with the specific
> data they need for
On Mon, 5 Feb 2018 14:53:55 +0100
Juri Lelli wrote:
> First impression is that this is going to be definitely useful if
>
> - it's possibile to hook at function end (e.g., replenish_dl_entity above
>carries more useful information _after_ it did its job)
The one issue is that you will only
On Sun, 4 Feb 2018 11:25:20 +0900
Namhyung Kim wrote:
> I'm interested in this. From my understanding, it's basically
> function tracing + filter + custom argument info, right?
>
> Supporting arguments with complex type could be error-prone.
> We need to prevent malfunctions by invalid inputs.
On Sun, 4 Feb 2018 09:21:30 -0800
Alexei Starovoitov wrote:
> On Sun, Feb 04, 2018 at 12:57:47PM +0900, Masami Hiramatsu wrote:
> >
> > > I based some of the code from kprobes too. But I wanted this to be
> > > simpler, and as such, not as powerful as kprobes. More of a "poor mans"
> > > kprobe
Hi Steve,
On 03/02/18 16:17, Steven Rostedt wrote:
> On Sat, 3 Feb 2018 12:52:08 -0800
> Alexei Starovoitov wrote:
>
> > It's a user space job.
>
> BTW, I asked around at DevConf.cz, and nobody I talked with (besides
> Arnaldo), have used eBPF. The "path to hello world" is quite high. This
> in
On 02/05/2018 11:23 AM, Juri Lelli wrote:
> Hi Steve,
>
> On 02/02/18 18:04, Steven Rostedt wrote:
>>
>> At Kernel Summit back in October, we tried to bring up trace markers, which
>> would be nops within the kernel proper, that would allow modules to hook
>> arbitrary trace events to them. The re
Hi Steve,
On 02/02/18 18:04, Steven Rostedt wrote:
>
> At Kernel Summit back in October, we tried to bring up trace markers, which
> would be nops within the kernel proper, that would allow modules to hook
> arbitrary trace events to them. The reaction to this proposal was less than
> favorable.
On Sun, Feb 04, 2018 at 11:39:39AM -0800, Linus Torvalds wrote:
> Then there's the "I just want an overview" MIS people, who care about
> things like "I want a histogram of packets sent according to criteria
> XYZ", who want some highlevel block IO performance, or who just want
> random system-wide
On Sun, Feb 4, 2018 at 7:30 AM, Mathieu Desnoyers
wrote:
>
> I agree with your arguments. A consequence of those arguments is that
> function-based tracing should be expected to be used by kernel engineers
> and experts who can adapt their scripts to follow code changes, and tune
> the script base
On Sun, Feb 04, 2018 at 12:57:47PM +0900, Masami Hiramatsu wrote:
>
> > I based some of the code from kprobes too. But I wanted this to be
> > simpler, and as such, not as powerful as kprobes. More of a "poor mans"
> > kprobe ;-) Where you are limited to functions and their arguments. If
> > you n
- On Feb 3, 2018, at 4:08 PM, rostedt rost...@goodmis.org wrote:
> On Sat, 3 Feb 2018 12:52:08 -0800
> Alexei Starovoitov wrote:
>
>> On Sat, Feb 03, 2018 at 02:02:17PM -0500, Steven Rostedt wrote:
>> >
>> > From those that were asking about having "trace markers" (ie.
>> > Facebook), they
On Sun, 4 Feb 2018 15:30:04 + (UTC)
Mathieu Desnoyers wrote:
> This should therefore leave a door open to adding new tracepoints: cases
> where the data gathered is shown to be useful enough for tools targeting
> an audience wider than just kernel developers. To improve over the current
> sit
- On Feb 3, 2018, at 4:43 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Sat, Feb 3, 2018 at 9:04 AM, Mathieu Desnoyers
> wrote:
>>
>> The approach proposed here will introduce an expectation that internal
>> function signatures never change in the kernel, else it would break
On Sat, 3 Feb 2018 10:27:59 -0500
Steven Rostedt wrote:
> On Sat, 3 Feb 2018 22:38:17 +0900
> Masami Hiramatsu wrote:
>
> > This seems very similar feature of what kprobe-based event does.
>
> It is similar, but not the same as kprobes. It only focuses on
> functions and their arguments, and s
On Sun, Feb 4, 2018 at 6:30 AM, Alexei Starovoitov
wrote:
> On Sat, Feb 03, 2018 at 04:08:24PM -0500, Steven Rostedt wrote:
>> OK, so no new development in this was wanted? So the entire talk about
>> getting tracepoints into vfs and scheduling wasn't needed?
>
> I don't know who wants tracepoints
Hi Steve and Alexei,
On Sun, Feb 4, 2018 at 6:17 AM, Steven Rostedt wrote:
> On Sat, 3 Feb 2018 12:52:08 -0800
> Alexei Starovoitov wrote:
>
>> It's a user space job.
>
> BTW, I asked around at DevConf.cz, and nobody I talked with (besides
> Arnaldo), have used eBPF. The "path to hello world" is
On Sat, Feb 3, 2018 at 9:04 AM, Mathieu Desnoyers
wrote:
>
> The approach proposed here will introduce an expectation that internal
> function signatures never change in the kernel, else it would break user-space
> tools hooking on those functions.
No, I really don't think so.
There's two reason
On Sat, Feb 03, 2018 at 04:17:32PM -0500, Steven Rostedt wrote:
> On Sat, 3 Feb 2018 12:52:08 -0800
> Alexei Starovoitov wrote:
>
> > It's a user space job.
>
> BTW, I asked around at DevConf.cz, and nobody I talked with (besides
> Arnaldo), have used eBPF. The "path to hello world" is quite hig
On Sat, Feb 03, 2018 at 04:08:24PM -0500, Steven Rostedt wrote:
> On Sat, 3 Feb 2018 12:52:08 -0800
> Alexei Starovoitov wrote:
>
> > On Sat, Feb 03, 2018 at 02:02:17PM -0500, Steven Rostedt wrote:
> > >
> > > From those that were asking about having "trace markers" (ie.
> > > Facebook), they to
On Sat, 3 Feb 2018 12:52:08 -0800
Alexei Starovoitov wrote:
> It's a user space job.
BTW, I asked around at DevConf.cz, and nobody I talked with (besides
Arnaldo), have used eBPF. The "path to hello world" is quite high. This
interface is extremely simple to use, and one doesn't need to install
On Sat, 3 Feb 2018 12:52:08 -0800
Alexei Starovoitov wrote:
> On Sat, Feb 03, 2018 at 02:02:17PM -0500, Steven Rostedt wrote:
> >
> > From those that were asking about having "trace markers" (ie.
> > Facebook), they told us they can cope with kernel changes.
>
> There is some misunderstanding
On Sat, Feb 03, 2018 at 02:02:17PM -0500, Steven Rostedt wrote:
>
> From those that were asking about having "trace markers" (ie.
> Facebook), they told us they can cope with kernel changes.
There is some misunderstanding here.
We never asked for this interface.
We're perfectly fine with existing
On Sat, 3 Feb 2018 17:04:14 + (UTC)
Mathieu Desnoyers wrote:
> The approach proposed here will introduce an expectation that internal
> function signatures never change in the kernel, else it would break user-space
> tools hooking on those functions.
I had this exact discussion with Linus.
I need to add a "Quick guide" and "Tips and tricks" section to the
document. To explain the arguments better...
Simple args are:
"int val", "unsigned int val", "char x", "unsigned long addr",
Also the types:
"s32 val", "u32 val", "s8 x", "u64 addr"
The above are all printed in decimal "%d"
- On Feb 2, 2018, at 6:04 PM, rostedt rost...@goodmis.org wrote:
> At Kernel Summit back in October, we tried to bring up trace markers, which
> would be nops within the kernel proper, that would allow modules to hook
> arbitrary trace events to them. The reaction to this proposal was less tha
On Sat, 3 Feb 2018 22:38:17 +0900
Masami Hiramatsu wrote:
> This seems very similar feature of what kprobe-based event does.
It is similar, but not the same as kprobes. It only focuses on
functions and their arguments, and should not require any disassembling
(no knowledge of regs required). Any
On Fri, 02 Feb 2018 18:04:58 -0500
Steven Rostedt wrote:
>
> At Kernel Summit back in October, we tried to bring up trace markers, which
> would be nops within the kernel proper, that would allow modules to hook
> arbitrary trace events to them. The reaction to this proposal was less than
> favo
At Kernel Summit back in October, we tried to bring up trace markers, which
would be nops within the kernel proper, that would allow modules to hook
arbitrary trace events to them. The reaction to this proposal was less than
favorable. We were told that we were trying to make a work around for a
p
30 matches
Mail list logo
