Messages in this thread | | | Subject | Re: [PATCH 3/3] mm: mmap_lock: add ip to mmap_lock tracepoints | From | Gang Li <> | Date | Fri, 20 Aug 2021 02:18:29 +0800 |
| |
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.
| |