You can't && event ids in config, it'll simply give a different event. You need to open a stream per tracing event.
On Wed, Apr 1, 2015 at 2:49 PM, sahil aggarwal <[email protected]> wrote: > If i enable multiple tracepoints, say: > > type = PERF_TYPE_TRACEPOINT > config = 87 | 402 (sched/sched_switch && syscalls/sys_enter_open) > sample_type = PERF_SAMPLE_TIME | > PERF_SAMPLE_RAW | > PERF_SAMPLE_TID | > PERF_SAMPLE_STREAM_ID ; > > It gives me some ID when i print sample_id(i thought it will print > config value). But how i can connect this ID with my type of event > (sched_switch or sys_enter_open). .? > > On 1 April 2015 at 15:34, sahil aggarwal <[email protected]> wrote: >> 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
