No i didn't give it a shot yet but code was very helpful. And, the raw data form was same as struct defined for event in format file(syscalls/sys_enter_open/format).
On 1 April 2015 at 15:28, Elazar Leibovich <[email protected]> wrote: > Yes, this is correct, as far as I can tell, when you create a perf_event for > every tracepoint event. > > I personally created a separate thread for each trace point, since I found > this approach simpler, but it is certainly possible to use a single thread + > select from all perf_event_open file descriptor. > > BTW, did you manage to experiment with perf using the tool I attached? > > On Wed, Apr 1, 2015 at 12:22 PM, sahil aggarwal <[email protected]> > wrote: >> >> Hi Elazar >> >> Finally i am able to make small prototype to enable tracepoints. :) >> >> One more thing, is it possible to enable multiple tracepoints through >> 1 thread and >> while parsing output find out to which tracepoint that raw data belongs.? >> >> Or i would have to create separate thread for each tracepoint. ? >> >> Man page says: >> Set config to one of the following: >> ......... >> >> So i am assuming i will have to create separate thread for each event. >> >> >> Thanks a lot. >> >> On 31 March 2015 at 23:37, Elazar Leibovich >> <[email protected]> wrote: >> > Look at the man page, you should set the type to PERF_TYPE_TRACEPOINT >> > and set the config to the event id. >> > >> > On my system, sys_enter_open event id is 455 >> > >> > $ sudo cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_open/id >> > 455 >> > >> > Add PERF_SAMPLE_RAW to the sample_type. >> > >> > BTW >> > You can compile the tar.gz I sent and echo JSON in the attr format to >> > it, it'll print back perf data in json format. Easier to experiment >> > with perf_event_open API than writing a C program. >> > >> > For example >> > >> > $ make >> > $ sudo ./perf2 <<EOF >> > { >> > "attr": { >> > "sample_type": [ >> > "PERF_SAMPLE_IP", >> > "PERF_SAMPLE_RAW" >> > ], >> > "wakeup_events": 1, >> > "config": 455, >> > "sample_period": 1, >> > "type": "PERF_TYPE_TRACEPOINT" >> > } >> > } >> > EOF >> > >> > {"type":"PERF_RECORD_SAMPLE","misc":"PERF_RECORD_MISC_USER","sample":{"ip":"7f4f3625263d","data":[-57,1,0,0,7,11,0,0,2,0,0,0,0,0,0,0,-32,101,75,22,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}} >> > >> > {"type":"PERF_RECORD_SAMPLE","misc":"PERF_RECORD_MISC_USER","sample":{"ip":"7f4f3625263d","data":[-57,1,0,0,7,11,0,0,2,0,0,0,0,0,0,0,-64,112,75,22,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}} >> > >> > {"type":"PERF_RECORD_SAMPLE","misc":"PERF_RECORD_MISC_USER","sample":{"ip":"7f4f3625263d","data":[-57,1,0,0,7,11,0,0,2,0,0,0,0,0,0,0,-112,70,75,22,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}} >> > >> > {"type":"PERF_RECORD_SAMPLE","misc":"PERF_RECORD_MISC_USER","sample":{"ip":"7f4f3625263d","data":[-57,1,0,0,7,11,0,0,2,0,0,0,0,0,0,0,-32,70,75,22,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}} >> > >> > {"type":"PERF_RECORD_SAMPLE","misc":"PERF_RECORD_MISC_USER","sample":{"ip":"7f4f3625263d","data":[-57,1,0,0,7,11,0,0,2,0,0,0,0,0,0,0,0,-99,26,-19,-1,127,0,0,0,0,0,0,0,0,0,0,-74,1,0,0,0,0,0,0,0,0,0,0]}} >> > ... >> > >> > What is the raw data? Depends on the event. For sys_enter/exit it is >> > struct syscall_trace_enter/exit. >> > >> > http://osxr.org/linux/source/kernel/trace/trace.h#0095 >> > struct trace_entry { >> > unsigned short type; >> > unsigned char flags; >> > unsigned char preempt_count; >> > int pid; >> > }; >> > struct syscall_trace_enter { >> > struct trace_entry ent; >> > int nr; >> > unsigned long args[]; >> > }; >> > >> > How did I know that? I followed the kernel logic here: >> > >> > http://osxr.org/linux/source/kernel/trace/trace_syscalls.c#0636 >> > static void perf_syscall_exit(void *ignore, struct pt_regs *regs, long >> > ret) >> > { >> > ... >> > rec = (struct syscall_trace_exit *)perf_trace_buf_prepare(size, ...); >> > ... >> > } >> > >> > Note that indeed after short+char+char+int we have 2, the open syscall >> > number in all event's raw data. >> > >> > On Tue, Mar 31, 2015 at 6:22 PM, sahil aggarwal <[email protected]> >> > wrote: >> >> Actually i need most of the sampling around PERF_TYPE_TRACEPOINT, >> >> so if i enable tracepoint "syscalls/sys_enter_open/" what will be the >> >> "type" >> >> field in perf_event_header.? And, the the record struct will be same as >> >> given >> >> in "syscalls/sys_enter_open/format" .? >> >> >> >> Thanks >> >> >> >> On 31 March 2015 at 20:40, sahil aggarwal <[email protected]> >> >> wrote: >> >>> Yeah that was clear enough. >> >>> Thanks a lot. Your code is of great help. >> >>> >> >>> Regards >> >>> Sahil >> >>> >> >>> On 31 March 2015 at 19:45, Elazar Leibovich >> >>> <[email protected]> wrote: >> >>>> I wanted to ensure the user always see contiguous array of data from >> >>>> the ring buffer. >> >>>> >> >>>> The last piece of data, say "abcde" could wrap around in the ring >> >>>> buffer and appear like: >> >>>> >> >>>> [de... ...abc] >> >>>> >> >>>> I wanted the user to see a contigious array of the form [abcde]. >> >>>> >> >>>> So in the case I'm having input that wrap around, I'll simply copy it >> >>>> to the first buffer >> >>>> >> >>>> [wrap_buffer][de.. ...abc] >> >>>> would become >> >>>> [ abc][de... ...abc] >> >>>> >> >>>> And then I'll the user pointer to the leftmost "a", and he'll see >> >>>> "abcde" without knowing he's handling a ring buffer. >> >>>> >> >>>> Let me know if I was clear enough. >> >>>> >> >>>> On Tue, Mar 31, 2015 at 2:18 PM, sahil aggarwal >> >>>> <[email protected]> wrote: >> >>>>> >> >>>>> Hi Elazar >> >>>>> >> >>>>> Can you help me understand why you have used >> >>>>> mmap_pages->wrap_base.? And, instead of allocating >> >>>>> (2^n)+1 pages you allocate (2^n)+2 pages, why so.? >> >>>>> wrap_base points to (2^n)+2 pages and base points to >> >>>>> (2^n)+1 pages, what is use of wrap_base.? I tried reading >> >>>>> perf source too, there it seems they use (2^n)+1 pages only. >> >>>>> >> >>>>> >> >>>>> Thanks >> >>>>> Regards >> >> -- >> >> To unsubscribe from this list: send the line "unsubscribe >> >> linux-perf-users" in >> >> the body of a message to [email protected] >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
