Yeah you are right. And, there seem to be problem when i declare 'struct perf_event_attr' at run time. Is it know issue.? It gives me -EINVAL(Invalid Argument).
Run Time: perf_event_open(0x22a20b8, 0, 0xffffffff, 0xffffffff, 0) = -1 EINVAL (Invalid argument) Compile Time: perf_event_open(0x7fffa242ee50, 0xffffffff, 0x1, 0xffffffff, 0) = 6 On 2 April 2015 at 00:20, Elazar Leibovich <[email protected]> wrote: > 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
