On 10/15/18 4:33 PM, Song Liu wrote: > I am working with Alexei on the idea of fetching BPF program information via > BPF_OBJ_GET_INFO_BY_FD cmd. I added PERF_RECORD_BPF_EVENT > to perf_event_type, and dumped these events to perf event ring buffer. > > I found that perf will not process event until the end of perf-record: > > root@virt-test:~# ~/perf record -ag -- sleep 10 > ...... 10 seconds later > [ perf record: Woken up 34 times to write data ] > machine__process_bpf_event: prog_id 6 loaded > machine__process_bpf_event: prog_id 6 unloaded > [ perf record: Captured and wrote 9.337 MB perf.data (93178 samples) ] > > In this example, the bpf program was loaded and then unloaded in > another terminal. When machine__process_bpf_event() processes > the load event, the bpf program is already unloaded. Therefore, > machine__process_bpf_event() will not be able to get information > about the program via BPF_OBJ_GET_INFO_BY_FD cmd. > > To solve this problem, we will need to run BPF_OBJ_GET_INFO_BY_FD > as soon as perf get the event from kernel. I looked around the perf > code for a while. But I haven't found a good example where some > events are processed before the end of perf-record. Could you > please help me with this?
perf record does not process events as they are generated. Its sole job is pushing data from the maps to a file as fast as possible meaning in bulk based on current read and write locations. Adding code to process events will add significant overhead to the record command and will not really solve your race problem.
