Re: [PATCH 3/3] mm: mmap_lock: add ip to mmap_lock tracepoints

[Gang Li]

On 8/2/21 10:44 AM, Gang Li wrote:
> On 7/31/21 4:03 AM, Steven Rostedt wrote:
> > Yes, synthetic events are just like normal events, and have triggers,
> > stack traces, and do pretty much anything that another event can do.
> >
> > I'm just finishing up a libtracfs called tracefs_sql() (hopefully
> > posting it today), that allows you to create a synthetic event via an
> > SQL statement. But I don't think this is what you are looking for.
> >
> > What about using function tracing? Because the tracepoint is called
> > from __mmap_lock* helper functions that function tracer can see, you
> > can just do the following:
> >
> >   # trace-cmd start -e mmap_lock -p function -l '__mmap_lock_*'
> >   # trace-cmd show
> > [..]
> >         trace-cmd-1840    [006] ....   194.576801: 
> > __mmap_lock_do_trace_start_locking <-do_user_addr_fault
> >         trace-cmd-1840    [006] ...1   194.576805: 
> > mmap_lock_start_locking: mm=000000006515cb1f 
> > memcg_path=/user.slice/user-0.slice/session-2.scope write=false
Hi!

I find that sometimes the output data is out of order, which leads to 
inaccurate time stamps and make it hard to analyse.

            node-953     [001] ....   203.823297: 
__mmap_lock_do_trace_start_locking <-do_user_addr_fault
            node-955     [002] ....   203.823297: 
__mmap_lock_do_trace_start_locking <-do_user_addr_fault
            node-956     [003] ....   203.823297: 
__mmap_lock_do_trace_start_locking <-do_user_addr_fault
            node-953     [001] ....   203.823297: 
mmap_lock_start_locking: mm=000000004395a005 
memcg_path=/user.slice/user-0.slice/session-1.scope write=false 
ip=do_user_addr_fault+0x270/0x4d0
            node-953     [001] ....   203.823298: 
__mmap_lock_do_trace_acquire_returned <-do_user_addr_fault

Is there any other way to collect ip in each event? It seems that adding 
"ip" fields is the only way to do this accurately and effectively.