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
