All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: Axel Rasmussen <axelrasmussen@google.com>,
	Ingo Molnar <mingo@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Michel Lespinasse <walken@google.com>,
	Daniel Jordan <daniel.m.jordan@oracle.com>,
	Davidlohr Bueso <dbueso@suse.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>
Subject: Re: [PATCH] mmap_lock: add tracepoints around lock acquisition
Date: Tue, 22 Sep 2020 12:51:13 -0400	[thread overview]
Message-ID: <20200922125113.12ef1e03@gandalf.local.home> (raw)
In-Reply-To: <CALOAHbBr=ASfvHw1ZscWBE=CY-e7sBrLV0F5Ow=g1UGxmQsWcw@mail.gmail.com>

On Tue, 22 Sep 2020 12:09:19 +0800
Yafang Shao <laoar.shao@gmail.com> wrote:

> > > Are there any methods to avoid un-inlining these wrappers ?
> > >
> > > For example,
> > > // include/linux/mmap_lock.h
> > >
> > > void mmap_lock_start_trace_wrapper();
> > > void mmap_lock_acquire_trace_wrapper();
> > >
> > > static inline void mmap_write_lock(struct mm_struct *mm)
> > > {
> > >     mmap_lock_start_trace_wrapper();
> > >     down_write(&mm->mmap_lock);
> > >     mmap_lock_acquire_trace_wrapper();
> > > }
> > >
> > > // mm/mmap_lock.c
> > > void mmap_lock_start_trace_wrapper()
> > > {
> > >     trace_mmap_lock_start();
> > > }
> > >
> > > void mmap_lock_start_trace_wrapper()
> > > {
> > >     trace_mmap_lock_acquired();
> > > }  
> >
> > We can do something like that, but I don't think it would end up being better.
> >
> > At the end of the day, because the trace stuff cannot be in the
> > header, we have to add an extra function call one way or the other.
> > This would just move the call one step further down the call stack.
> > So, I don't think it would affect performance in the
> > CONFIG_MMAP_LOCK_STATS + tracepoints not enabled at runtime case.
> >  
> 
> Right, it seems we have to add an extra function call.
> 
> > Also the wrappers aren't quite so simple as this, they need some
> > parameters to work. (the struct mm_struct, whether it was a read or a
> > write lock, and whether or not the lock operation succeeded), so it
> > would mean adding more inlined code, which I think adds up to be a
> > nontrivial amount since these wrappers are called so often in the
> > kernel.
> >
> > If you feel strongly, let me know and I can send a version as you
> > describe and we can compare the two.
> >  
> 
> These tracepoints will be less useful if we have to turn on the config
> to enable it.
> I don't mind implementing it that way if we can't optimize it.
> 
> Maybe Steven can give some suggestions, Steven ?
> 


What you can do, and what we have done is the following:

(see include/linux/page_ref.h)


#ifdef CONFIG_TRACING
extern struct tracepoint __tracepoint_mmap_lock_start_locking;
extern struct tracepoint __tracepoint_mmap_lock_acquire_returned;

#define mmap_lock_tracepoint_active(t) static_key_false(&(__tracepoint_mmap_lock_##t).key)

#else
#define mmap_lock_tracepoint_active(t) false
#endif

static inline void mmap_write_lock(struct mm_struct *mm)
{
	if (mmap_lock_tracepoint_active(start_locking))
		mmap_lock_start_trace_wrapper();
	down_write(&mm->mmap_lock);
	if (mmap_lock_tracepoint_active(acquire_returned))
		mmap_lock_acquire_trace_wrapper();
}


-- Steve

  parent reply	other threads:[~2020-09-22 16:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-17 18:13 [PATCH] mmap_lock: add tracepoints around lock acquisition Axel Rasmussen
2020-09-17 18:13 ` Axel Rasmussen
2020-09-17 19:42 ` Steven Rostedt
2020-09-18 20:26   ` Axel Rasmussen
2020-09-18 20:26     ` Axel Rasmussen
2020-09-18 20:41     ` Steven Rostedt
2020-09-23 22:07       ` Tom Zanussi
2020-09-23 22:07         ` Tom Zanussi
2020-09-21  4:57 ` Yafang Shao
2020-09-21  4:57   ` Yafang Shao
2020-09-21 16:53   ` Axel Rasmussen
2020-09-21 16:53     ` Axel Rasmussen
2020-09-22  4:09     ` Yafang Shao
2020-09-22  4:09       ` Yafang Shao
2020-09-22 16:39       ` Axel Rasmussen
2020-09-22 16:39         ` Axel Rasmussen
2020-09-22 16:51       ` Steven Rostedt [this message]
2020-09-23 10:04         ` Yafang Shao
2020-09-23 10:04           ` Yafang Shao
2020-09-23 16:09           ` Steven Rostedt
2020-09-23 16:40             ` Axel Rasmussen
2020-09-23 16:40               ` Axel Rasmussen
2020-09-24  4:28             ` Yafang Shao
2020-09-24  4:28               ` Yafang Shao

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=20200922125113.12ef1e03@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=daniel.m.jordan@oracle.com \
    --cc=dbueso@suse.de \
    --cc=laoar.shao@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=vbabka@suse.cz \
    --cc=walken@google.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.