Sorry for that dumb ques. Problem was somewhere else.
On 2 April 2015 at 19:00, sahil aggarwal <[email protected]> wrote: > 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
