From: Gang Li <email@example.com> To: Axel Rasmussen <firstname.lastname@example.org> Cc: Steven Rostedt <email@example.com>, Ingo Molnar <firstname.lastname@example.org>, Andrew Morton <email@example.com>, Vlastimil Babka <firstname.lastname@example.org>, LKML <email@example.com>, Linux MM <firstname.lastname@example.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: <email@example.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 <firstname.lastname@example.org> > > 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 <email@example.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 <firstname.lastname@example.org>
next prev parent 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --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).