linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>, Will Deacon <will@kernel.org>,
	Waiman Long <longman@redhat.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Byungchul Park <byungchul.park@lge.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Arnd Bergmann <arnd@arndb.de>, Radoslaw Burny <rburny@google.com>,
	linux-arch <linux-arch@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>, Hyeonggon Yoo <42.hyeyoo@gmail.com>
Subject: Re: [PATCH 2/2] locking: Apply contention tracepoints in the slow path
Date: Mon, 28 Mar 2022 10:48:59 -0700	[thread overview]
Message-ID: <CAM9d7ciQQEypvv2a2zQLHNc7p3NNxF59kASxHoFMCqiQicKwBA@mail.gmail.com> (raw)
In-Reply-To: <20220328113946.GA8939@worktop.programming.kicks-ass.net>

On Mon, Mar 28, 2022 at 4:39 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Tue, Mar 22, 2022 at 11:57:09AM -0700, Namhyung Kim wrote:
> > diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> > index ee2fd7614a93..c88deda77cf2 100644
> > --- a/kernel/locking/mutex.c
> > +++ b/kernel/locking/mutex.c
> > @@ -644,6 +644,7 @@ __mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclas
> >       }
> >
> >       set_current_state(state);
> > +     trace_contention_begin(lock, 0);
> >       for (;;) {
> >               bool first;
> >
> > @@ -710,6 +711,7 @@ __mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclas
> >  skip_wait:
> >       /* got the lock - cleanup and rejoice! */
> >       lock_acquired(&lock->dep_map, ip);
> > +     trace_contention_end(lock, 0);
> >
> >       if (ww_ctx)
> >               ww_mutex_lock_acquired(ww, ww_ctx);
>
> (note: it's possible to get to this trace_contention_end() without ever
> having passed a _begin -- fixed in the below)
>
> > @@ -721,6 +723,7 @@ __mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclas
> >  err:
> >       __set_current_state(TASK_RUNNING);
> >       __mutex_remove_waiter(lock, &waiter);
> > +     trace_contention_end(lock, ret);
> >  err_early_kill:
> >       raw_spin_unlock(&lock->wait_lock);
> >       debug_mutex_free_waiter(&waiter);
>
>
> So there was one thing here, that might or might not be important, but
> is somewhat inconsistent with the whole thing. That is, do you want to
> include optimistic spinning in the contention time or not?

Yes, this was in a grey area and would create begin -> begin -> end
path for mutexes.  But I think tools can handle it with the flags.

>
> Because currently you do it sometimes.
>
> Also, if you were to add LCB_F_MUTEX then you could have something like:

Yep, I'm ok with having the mutex flag.  Do you want me to send
v5 with this change or would you like to do it by yourself?

Thanks,
Namhyung


>
>
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -602,12 +602,14 @@ __mutex_lock_common(struct mutex *lock,
>         preempt_disable();
>         mutex_acquire_nest(&lock->dep_map, subclass, 0, nest_lock, ip);
>
> +       trace_contention_begin(lock, LCB_F_MUTEX | LCB_F_SPIN);
>         if (__mutex_trylock(lock) ||
>             mutex_optimistic_spin(lock, ww_ctx, NULL)) {
>                 /* got the lock, yay! */
>                 lock_acquired(&lock->dep_map, ip);
>                 if (ww_ctx)
>                         ww_mutex_set_context_fastpath(ww, ww_ctx);
> +               trace_contention_end(lock, 0);
>                 preempt_enable();
>                 return 0;
>         }
> @@ -644,7 +646,7 @@ __mutex_lock_common(struct mutex *lock,
>         }
>
>         set_current_state(state);
> -       trace_contention_begin(lock, 0);
> +       trace_contention_begin(lock, LCB_F_MUTEX);
>         for (;;) {
>                 bool first;
>
> @@ -684,10 +686,16 @@ __mutex_lock_common(struct mutex *lock,
>                  * state back to RUNNING and fall through the next schedule(),
>                  * or we must see its unlock and acquire.
>                  */
> -               if (__mutex_trylock_or_handoff(lock, first) ||
> -                   (first && mutex_optimistic_spin(lock, ww_ctx, &waiter)))
> +               if (__mutex_trylock_or_handoff(lock, first))
>                         break;
>
> +               if (first) {
> +                       trace_contention_begin(lock, LCB_F_MUTEX | LCB_F_SPIN);
> +                       if (mutex_optimistic_spin(lock, ww_ctx, &waiter))
> +                               break;
> +                       trace_contention_begin(lock, LCB_F_MUTEX);
> +               }
> +
>                 raw_spin_lock(&lock->wait_lock);
>         }
>         raw_spin_lock(&lock->wait_lock);
> @@ -723,8 +731,8 @@ __mutex_lock_common(struct mutex *lock,
>  err:
>         __set_current_state(TASK_RUNNING);
>         __mutex_remove_waiter(lock, &waiter);
> -       trace_contention_end(lock, ret);
>  err_early_kill:
> +       trace_contention_end(lock, ret);
>         raw_spin_unlock(&lock->wait_lock);
>         debug_mutex_free_waiter(&waiter);
>         mutex_release(&lock->dep_map, ip);

  reply	other threads:[~2022-03-28 17:49 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-22 18:57 [PATCH 0/2] locking: Add new lock contention tracepoints (v4) Namhyung Kim
2022-03-22 18:57 ` [PATCH 1/2] locking: Add lock contention tracepoints Namhyung Kim
2022-03-22 18:57 ` [PATCH 2/2] locking: Apply contention tracepoints in the slow path Namhyung Kim
2022-03-28 11:29   ` Peter Zijlstra
2022-03-28 17:41     ` Namhyung Kim
2022-03-28 11:39   ` Peter Zijlstra
2022-03-28 17:48     ` Namhyung Kim [this message]
2022-03-30 11:08       ` Peter Zijlstra
2022-03-30 19:03         ` Namhyung Kim
2022-03-31 11:59           ` Peter Zijlstra
2022-04-01  6:26             ` Namhyung Kim
2022-04-01  9:25               ` Peter Zijlstra
  -- strict thread matches above, loose matches on Subject: below --
2022-03-16 22:45 [PATCH 0/2] locking: Add new lock contention tracepoints (v3) Namhyung Kim
2022-03-16 22:45 ` [PATCH 2/2] locking: Apply contention tracepoints in the slow path Namhyung Kim
2022-03-17 13:45   ` Mathieu Desnoyers
2022-03-17 16:10     ` Steven Rostedt
2022-03-17 16:43       ` Mathieu Desnoyers
2022-03-18 21:34     ` Namhyung Kim
2022-03-17 18:19   ` Hyeonggon Yoo
2022-03-18 21:43     ` Namhyung Kim
2022-03-18 12:55   ` Boqun Feng
2022-03-18 13:24     ` Hyeonggon Yoo
2022-03-18 13:28       ` Hyeonggon Yoo
2022-03-18 16:43     ` Peter Zijlstra
2022-03-18 21:55       ` Namhyung Kim
2022-03-18 22:07         ` Steven Rostedt
2022-03-19  0:11           ` Namhyung Kim
2022-03-22  5:31             ` Namhyung Kim
2022-03-22 12:59               ` Steven Rostedt
2022-03-22 16:39                 ` Namhyung Kim

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=CAM9d7ciQQEypvv2a2zQLHNc7p3NNxF59kASxHoFMCqiQicKwBA@mail.gmail.com \
    --to=namhyung@kernel.org \
    --cc=42.hyeyoo@gmail.com \
    --cc=arnd@arndb.de \
    --cc=boqun.feng@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=byungchul.park@lge.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rburny@google.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    /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 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).