public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Carlos Llamas <cmllamas@google.com>
To: Alice Ryhl <aliceryhl@google.com>
Cc: "Arve Hjønnevåg" <arve@android.com>,
	"Christian Brauner" <brauner@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Joel Fernandes" <joel@joelfernandes.org>,
	kernel-team@android.com, linux-kernel@vger.kernel.org,
	"Martijn Coenen" <maco@android.com>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Todd Kjos" <tkjos@android.com>
Subject: Re: [PATCH 21/21] binder: switch alloc->mutex to spinlock_t
Date: Fri, 1 Dec 2023 07:46:31 +0000	[thread overview]
Message-ID: <ZWmPV-N7Ua795HQ9@google.com> (raw)
In-Reply-To: <20231107090849.262070-1-aliceryhl@google.com>

On Tue, Nov 07, 2023 at 09:08:49AM +0000, Alice Ryhl wrote:
> Carlos Llamas <cmllamas@google.com> writes:
> > The alloc->mutex is a highly contended lock that causes performance
> > issues on Android devices. When a low-priority task is given this lock
> > and it sleeps, it becomes difficult for the task to wakeup and complete
> > its work. This delays other tasks that are also waiting on the mutex.
> 
> Grammar nit: "to wake up"

OK.

> 
> > The problem gets worse when there is memory pressure in the system,
> > because this increases the contention on the alloc->mutex while the
> > shrinker reclaims binder pages.
> > 
> > Switching to a spinlock helps to keep the waiters running and avoids the
> > overhead of waking up tasks. This significantly improves the transaction
> > latency when the problematic scenario occurs.
> >
> > [snip]
> >
> > Note that it is only possible to convert this lock after a series of
> > changes made by previous patches. These mainly include refactoring the
> > sections that might_sleep() and changing the locking order with the
> > mmap_lock amongst others.
> > 
> > Signed-off-by: Carlos Llamas <cmllamas@google.com>
> 
> Nice!
> 
> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
> 
> >  	 * binder_free_buf_locked(). However, that could
> > -	 * increase contention for the alloc mutex if clear_on_free
> > -	 * is used frequently for large buffers. The mutex is not
> > +	 * increase contention for the alloc->lock if clear_on_free
> > +	 * is used frequently for large buffers. This lock is not
> 
> Grammar nit: Shouldn't this say "However, that could increase contention
> on alloc->lock if clear_on_free is used frequently for large buffers."?

Do you mean "contention for" vs "contention on"? They both seem correct
to me but this was written by Todd, so I'd trust his english much more
than mine.

--
Carlos Llamas

      reply	other threads:[~2023-12-01  7:46 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-02 18:59 [PATCH 00/21] binder: convert alloc->mutex to spinlock Carlos Llamas
2023-11-02 18:59 ` [PATCH 01/21] binder: use EPOLLERR from eventpoll.h Carlos Llamas
2023-11-07  9:07   ` Alice Ryhl
2023-11-02 18:59 ` [PATCH 02/21] binder: fix use-after-free in shinker's callback Carlos Llamas
2023-11-02 19:20   ` Liam R. Howlett
2023-11-02 20:09     ` Carlos Llamas
2023-11-02 20:27       ` Liam R. Howlett
2023-11-07  9:07   ` Alice Ryhl
2023-11-02 18:59 ` [PATCH 03/21] binder: fix race between mmput() and do_exit() Carlos Llamas
2023-11-07  9:07   ` Alice Ryhl
2023-11-02 18:59 ` [PATCH 04/21] binder: fix async space check for 0-sized buffers Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-11-02 18:59 ` [PATCH 05/21] binder: fix trivial typo of binder_free_buf_locked() Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-12-01  6:52     ` Carlos Llamas
2023-11-02 18:59 ` [PATCH 06/21] binder: fix comment on binder_alloc_new_buf() return value Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-11-02 18:59 ` [PATCH 07/21] binder: remove extern from function prototypes Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-11-02 18:59 ` [PATCH 08/21] binder: keep vma addresses type as unsigned long Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-12-01  7:01     ` Carlos Llamas
2023-11-02 18:59 ` [PATCH 09/21] binder: split up binder_update_page_range() Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-12-01  7:03     ` Carlos Llamas
2023-11-02 18:59 ` [PATCH 10/21] binder: do unlocked work in binder_alloc_new_buf() Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-12-01  7:10     ` Carlos Llamas
2023-11-02 18:59 ` [PATCH 11/21] binder: remove pid param " Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-11-02 18:59 ` [PATCH 12/21] binder: separate the no-space debugging logic Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-11-02 18:59 ` [PATCH 13/21] binder: relocate low space calculation Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-12-01  7:12     ` Carlos Llamas
2023-11-02 18:59 ` [PATCH 14/21] binder: do not add pages to LRU in release path Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-12-01  7:15     ` Carlos Llamas
2023-11-02 18:59 ` [PATCH 15/21] binder: relocate binder_alloc_clear_buf() Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-11-02 18:59 ` [PATCH 16/21] binder: refactor page range allocation Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-12-01  7:19     ` Carlos Llamas
2023-11-02 18:59 ` [PATCH 17/21] binder: malloc new_buffer outside of locks Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-12-01  7:20     ` Carlos Llamas
2023-11-02 18:59 ` [PATCH 18/21] binder: initialize lru pages in mmap callback Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-11-02 18:59 ` [PATCH 19/21] binder: perform page allocation outside of locks Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-12-01  7:39     ` Carlos Llamas
2023-11-02 18:59 ` [PATCH 20/21] binder: reverse locking order in shrinker callback Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-12-01  7:42     ` Carlos Llamas
2023-11-02 18:59 ` [PATCH 21/21] binder: switch alloc->mutex to spinlock_t Carlos Llamas
2023-11-07  9:08   ` Alice Ryhl
2023-12-01  7:46     ` Carlos Llamas [this message]

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=ZWmPV-N7Ua795HQ9@google.com \
    --to=cmllamas@google.com \
    --cc=aliceryhl@google.com \
    --cc=arve@android.com \
    --cc=brauner@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=joel@joelfernandes.org \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maco@android.com \
    --cc=surenb@google.com \
    --cc=tkjos@android.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox