Hey Elazar,
In the example you sent me, if i set :
attr->inherit=1
Then,
mmap(mmap_pages->wrap_base + page_size, \
mmap_len - page_size, PROT_READ | \
PROT_WRITE, MAP_FIXED | MAP_SHARED, \
fd, 0);
call fails with "Invalid argument".
Happens only if inherit is set. Do i need to set any other flag
too.?
Thanks
Regards
On 3 April 2015 at 11:04, sahil aggarwal <[email protected]> wrote:
> 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
