On Mon, Mar 11, 2019 at 8:24 PM Kris Van Hees <kris.van.hees@xxxxxxxxxx> wrote: > > On Mon, Mar 11, 2019 at 06:29:55PM -0700, Brendan Gregg wrote: > > On Mon, Mar 11, 2019 at 7:21 AM Kris Van Hees <kris.van.hees@xxxxxxxxxx> wrote: > > > > > > On Thu, Mar 07, 2019 at 01:30:37PM -0800, Alexei Starovoitov wrote: > > > > On Tue, Mar 05, 2019 at 09:03:57PM -0500, Kris Van Hees wrote: > > [...] > > > > > But being able to do things like this without > > > > > needing to touch the context of any other BPF program type is a great benefit > > > > > to offer tracing tools, as far as I see it. > > > > > > > > I still don't understand what you're referring to by 'things like this' > > > > that somehow will be possible in the future, but not possible today. > > > > Could you please give concrete example? > > > > > > My apologies for not being clear. I am referring to the features of the > > > gtrace context in terms of containing task information, and output buffers > > > to be used in BPF programs triggered from various probe sources (kprobe, > > > tracepoints, ...) I would not want to suggest making changes to all the > > > different program contexts in order to support tracing needs because that > > > would be wrong. Doing it in a central place makes it a lot easier to maintain > > > without impacting other program types, etc. > > > > > > Of course, yes, bpf_probe_read() and bpf_perf_event_output() can be used > > > to implement a lot of what existing tracing tools like DTrace can do, if you > > > write them based on that. One limitations I am obviously working with is > > > that DTrace already exists and has existed for a long time. And while it is > > > 100% available as open source, it involves a pretty involved set of patches to > > > be applied to the kernel to be able to use it which is just not ideal. Hence > > > the goal to make it available by re-using as much of the existing features in > > > Linux as possible, while still maintaining the same level of functionality in > > > DTrace. That means we need to fill the gaps - and from where I am sitting, > > > the ways to do that might as well be of use to others (if they want to). > > > > > > If phrasing things in the context of DTrace would make the conversation easier > > > I certainly don;t mind doing that, but I really don't want to limit my patches > > > to supporting just DTrace (even if right now it might be the only tracer using > > > it). > > > > As a concrete example, can you point to one of my own published DTrace > > tools that BPF can't do? These were created to solve many real > > production issues, and make good use cases. I've been porting them > > over to BPF (bcc and bpftrace) without too much problem, and I can't > > think of a single one that I couldn't port over today. > > I am unclear how pointing at one of your published DTrace tools would > contribute to this discussion. Surely the scope of use cases is not limited > to the DTrace scripts you published? > > Either way, one of the features that I make use of is speculative tracing. The subject was a concrete example. I don't think I used speculative tracing in any of my scripts. Can you pick a better example of something BPF can't do? > And yes, even that could be handled with some ugly workarounds but my intent > is to implement things in a more clean way rather than depending on a bunch > of workarounds to make it somewhat work. > > > There's a few minor things that I'm currently doing workarounds for, > > like ppid, but that should be satisfied with a few more helpers. And > > if it's really niche, then BTF sounds like a good solution. > > Of course, we can always add more helpers to get to information that is > needed, but that is hardly a practical solution in the long run, and at > Plumbers 2019 it was already indicated that just adding helpers to get to > more information about tasks is not the route people want to take. > > > If your ultimate goal is to have a command called "dtrace" that runs D > > programs, to support your existing users, then I'd add a lex/yacc pair > > to bpftrace and have it emit a dtrace binary. > > My goal is not to have a command called dtarce that somehow simply provides > some form of support for dtrace scripts in some legacy support model. My > goal is to make DTrace available on Linux based on existing kernel features > (and contirbuting extra features where needed, in a collaborative manner). If bpftrace builds a dtrace binary that runs D code, then you just did make DTrace available on Linux. And without changing the kernel. Brendan -- Brendan Gregg, Senior Performance Architect, Netflix
