Digging a bit deep i found that if
pid > 0 && cpu == -1
then only mmap during attr->inherit=1 fails. what i could be missing.?
On 8 April 2015 at 11:38, sahil aggarwal <sahil.ag...@gmail.com> wrote:
> 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 <sahil.ag...@gmail.com> wrote:
>> Sorry for that dumb ques. Problem was somewhere else.
>>
>> On 2 April 2015 at 19:00, sahil aggarwal <sahil.ag...@gmail.com> 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
>>> <elazar.leibov...@ravellosystems.com> 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 <sahil.ag...@gmail.com>
>>>> 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 <sahil.ag...@gmail.com> 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
>>>>>> <elazar.leibov...@ravellosystems.com> 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 <sahil.ag...@gmail.com>
>>>>>>> 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
>>>>>>>> <elazar.leibov...@ravellosystems.com> 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
>>>>>>>> > <sahil.ag...@gmail.com>
>>>>>>>> > 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 <sahil.ag...@gmail.com>
>>>>>>>> >> 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
>>>>>>>> >>> <elazar.leibov...@ravellosystems.com> 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
>>>>>>>> >>>> <sahil.ag...@gmail.com> 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 majord...@vger.kernel.org
>>>>>>>> >> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
