ERR:75 & error: lost 36 events about ply

[wkz]

Well, basically your script is generating more data than ply can keep up with. By default ply will then exit rather than providing incomplete data; you can override this behavior with the -k option.

In general, using print/printf for these kinds of hot paths is not very useful. I would suggest trying to either filter the output using some predicate (e.g. are you only interested in a particular comm/pid) or aggregate the data (e.g. tracepoint:syscalls/sys_enter_close { @[data->fd] = count(); }).

Re: poll(2) vs. epoll(7)

Could you elaborate on the inferior performance of poll(2)? There is one fd per cpu in the poll set, so unless you are on a massive machine, I don't really see how that would matter much.

Re: perf vs ftrace

Not sure what you are referring to. The code uses perf events because that was the mechanism available at the time this code was written. Nowadays you could also use a bpf ring buffer, but I fail to see how this relates to ftrace.

[xumn3348]

thanks for your perfect replying.

poll(2) vs. epoll(7):
Although both sleep and alternate, select and poll need to traverse the entire FD set when they are "awake", while epoll only needs to judge whether the ready list is empty when they are "awake", which saves a lot of CPU time. This is the performance improvement brought by the callback mechanism.

perf vs ftrace：
you are right. BPF ringbuf is gooder than perfbuf. maybe i mistake ftrace for BPF .

[wkz]

I understand how epoll works. I just don't know if I buy the argument that traversing a small array is the limiting factor here. You would have to measure of course, but my guess would be that you are limited by whatever medium you are writing the output to (tty/disk/whatever).

Anyway, if I ever get around to improving this code, it will be to replace the perf event with a bpf ring buffer. In that case the poll set will shrink down to 1, so poll will most likely continue to work just fine.