On Wed, Nov 01, 2017 at 11:29:32AM -0400, Steven Rostedt wrote: > On Wed, 1 Nov 2017 08:27:43 +0200 > Leon Romanovsky <leon@xxxxxxxxxx> wrote: > > > On Mon, Oct 30, 2017 at 06:01:23PM -0400, Chuck Lever wrote: > > > These can be shared with all kernel ULPs, and more can easily be > > > added as needed. > > > > > > Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx> > > > --- > > > include/trace/events/rdma.h | 128 +++++++++++++++++++++++++++++++++++++++++++ > > > 1 file changed, 128 insertions(+) > > > create mode 100644 include/trace/events/rdma.h > > > > > > Hi- > > > > > > I'm putting together a series of patches for v4.16 (or later) that > > > add static ftrace trace points to the RPC-over-RDMA client imple- > > > mentation. As part of that effort, I've constructed some trace point > > > helpers that might be useful for other kernel ULPs. > > > > > > So far this patch adds just helpers that xprtrdma needs. It is not > > > complete, but additional helpers can be introduced as they are > > > needed. > > > > > > I'd like to hear comments about these, or please let me know if > > > such helpers already exist and where xprtrdma can find them. > > > > Bart, Steve > > > > You attended the MS track, and for the rest of us, the quote below > > sounds a little bit cryptic. Does the quote below mean that Chuck's > > proposal is no-go? > > Actually, I wasn't invited to the Maintainer's Summit. Perhaps I should > have been. > > > > > From LWN.net "Another attempt to address the tracepoint ABI problem" [1] > > > > "The solution that was arrived at for now, as related by Torvalds, > > is to hold off on adding explicit tracepoints to the kernel. Instead, > > support will be added to make it easy for an application to attach a > > BPF script to any function in the kernel, with access to that function's > > arguments." > > > > [1] https://lwn.net/Articles/737530/ > > What I can tell you is what I talked to Linus about when I cornered him > in the hallway. ;-) > > Basically, nothing has changed. If a maintainer is fine with > trace events, then they can add new trace events. The issue is with the > maintainers that don't want the possibility of having to maintain stale > trace events because some tool depends on them and it becomes a burden > in the future. This is mostly an issues with the scheduler and VFS. > > What Linus asked me to do is to build an infrastructure on top of > ftrace, and make it easier to extract data from these "dynamic function > trace events". I need to add easier use cases for eBPF because the > usage of eBPF is still a large learning curve compared to the ease of > accessing the current trace event infrastructure. > > I'll be working on this in the very near future, but I don't expect > anything to be useful for within a year's time. Thus, continue doing > what you have been doing, and hopefully in a year we will be able to > extract more data from the kernel from anywhere a function is traced. Thanks > > -- Steve >
Attachment:
signature.asc
Description: PGP signature
