On Tue, Dec 3, 2013 at 4:01 PM, Andi Kleen <a...@firstfloor.org> wrote: > Alexei Starovoitov <a...@plumgrid.com> writes: > > Can you do some performance comparison compared to e.g. ktap? > How much faster is it?
imo the most interesting ktap scripts (like kmalloc-top.kp) need tables and timers. tables are almost ready for prime time, but timers I prefer to keep out of kernel. I would like bpf filter to fill tables with interesting data in kernel up to predefined limit and periodically read and clear the tables from userspace. This way I will be able to do nettop.stp, iotop.stp like programs. So I'm still thinking what should be clean kernel/user interface for bpf-defined tables. Format of keys and elements of the table is defined within bpf program. During load of bpf program, the tables are allocated and bpf program can now lookup/update into them. At the same time corresponding userspace program can read tables of this particular bpf program over netlink. Creating its own debugfs files for every filter feels too slow and feature limited, since files are all or nothing interface. Netlink access to bpf tables feels cleaner. Userspace will use libmnl to access them. Other ideas? In the mean time I'll do some simple trace probe:xx { print } performance test… > While it sounds interesting, I would strongly advise to make this > capability only available to root. Traditionally lots of complex byte > code languages which were designed to be "safe" and verifiable weren't > really. e.g. i managed to crash things with "safe" systemtap multiple > times. And we all know what happened to Java. > > So the likelyhood of this having some hole somewhere (either in > the byte code or in some library function) is high. Tracing filters are for root only today and should stay this way. As far as safety of bpf… hard to argue systemtap point ;) Though existing bpf is generally accepted to be safe. extended bpf needs time to prove itself. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/