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. 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
