linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Gang Li <ligang.bdlg@bytedance.com>
To: Axel Rasmussen <axelrasmussen@google.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>
Subject: Re: Re: [PATCH 3/3] mm: mmap_lock: add ip to mmap_lock tracepoints
Date: Fri, 30 Jul 2021 13:32:12 +0800	[thread overview]
Message-ID: <585f936d-9d27-a481-f590-bd07f98f34de@bytedance.com> (raw)
In-Reply-To: <CAJHvVcjBH+Vry8v5T0FWyFWWDY6_AqSxZcVQxXRm=LR8v=ML-Q@mail.gmail.com>

Thanks! I have tried your suggestion. They are great, especially 
synthetic-events.

If don't print ip per event, we can only guess which one cause the 
contention by "hitcount".

 > 
(https://www.kernel.org/doc/html/latest/trace/histogram.html#synthetic-events)

But it seems that they only support histogram, can I print the
synthetic-events args per event in /sys/kernel/debug/tracing/trace
like other events? I haven't found that in kernel doc.

On 7/30/21 1:33 AM, Axel Rasmussen wrote:
> Not a strong objection, but I think this can be achieved already using either:
> 
> - The "stacktrace" feature which histogram triggers support
> (https://www.kernel.org/doc/html/latest/trace/histogram.html)
> - bpftrace's kstack/ustack feature
> (https://github.com/iovisor/bpftrace/blob/master/docs/tutorial_one_liners.md#lesson-9-profile-on-cpu-kernel-stacks)
> 
> I haven't tried it out myself, but I suspect you could construct a
> synthetic event
> (https://www.kernel.org/doc/html/latest/trace/histogram.html#synthetic-events)
> which adds in the stack trace, then it ought to function a lot like it
> would with this patch.
> 
> Then again, it's not like this change is huge by any means. So, if you
> find this more convenient than those alternatives, you can take:
> 
> Reviewed-by: Axel Rasmussen <axelrasmussen@google.com>
> 
> It's possible Steven or Tom have a more strong opinion on this though. ;)
> 
> On Thu, Jul 29, 2021 at 2:29 AM Gang Li <ligang.bdlg@bytedance.com> wrote:
>>
>> The mmap_lock is acquired on most (all?) mmap / munmap / page fault
>> operations, so a multi-threaded process which does a lot of these
>> can experience significant contention. Sometimes we want to know
>> where the lock is hold. And it's hard to locate without collecting ip.
>>
>> Here's an example: TP_printk("ip=%pS",ip)
>> Log looks like this: "ip=do_user_addr_fault+0x274/0x640"
>>
>> We can find out who cause the contention amd make some improvements
>> for it.
>>
>> Signed-off-by: Gang Li <ligang.bdlg@bytedance.com>



  reply	other threads:[~2021-07-30  5:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-29  9:28 Gang Li
2021-07-29 17:33 ` Axel Rasmussen
2021-07-30  5:32   ` Gang Li [this message]
2021-07-30 20:03     ` Steven Rostedt
2021-08-02  2:44       ` Gang Li
2021-08-19 18:18         ` Gang Li
2021-08-31  3:24           ` Gang Li
2021-07-30  8:12   ` Vlastimil Babka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=585f936d-9d27-a481-f590-bd07f98f34de@bytedance.com \
    --to=ligang.bdlg@bytedance.com \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=vbabka@suse.cz \
    --subject='Re: Re: [PATCH 3/3] mm: mmap_lock: add ip to mmap_lock tracepoints' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).