From mboxrd@z Thu Jan 1 00:00:00 1970 From: sahil aggarwal Subject: Re: perf smapling Date: Wed, 1 Apr 2015 17:19:42 +0530 Message-ID: References: <20150331111813.GA1152@ubuntu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from mail-ob0-f174.google.com ([209.85.214.174]:36262 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753335AbbDALtn (ORCPT ); Wed, 1 Apr 2015 07:49:43 -0400 Received: by obbec2 with SMTP id ec2so74065450obb.3 for ; Wed, 01 Apr 2015 04:49:43 -0700 (PDT) In-Reply-To: Sender: linux-perf-users-owner@vger.kernel.org List-ID: To: Elazar Leibovich Cc: linux-perf-users@vger.kernel.org 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 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 > 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 >> 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 >>> 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 <>> > { >>> > "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 >>> > 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 >>> >> 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 >>> >>> 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 >>> >>>> 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 majordomo@vger.kernel.org >>> >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >>