From: Carlos Llamas <cmllamas@google.com>
To: "Liam R. Howlett" <Liam.Howlett@oracle.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Arve Hjønnevåg" <arve@android.com>,
"Todd Kjos" <tkjos@android.com>,
"Martijn Coenen" <maco@android.com>,
"Joel Fernandes" <joel@joelfernandes.org>,
"Christian Brauner" <brauner@kernel.org>,
"Suren Baghdasaryan" <surenb@google.com>,
linux-kernel@vger.kernel.org, kernel-team@android.com,
"David Hildenbrand" <david@redhat.com>,
"Barry Song" <v-songbaohua@oppo.com>
Subject: Re: [PATCH v3 2/8] binder: concurrent page installation
Date: Fri, 8 Nov 2024 22:26:19 +0000 [thread overview]
Message-ID: <Zy6QC71iEy3w5FYA@google.com> (raw)
In-Reply-To: <xpzec7tqe43sykvqtgrlh3furu7vn2nrnkjmv7odzy7ywd4lf6@hlawbgapxcfk>
On Fri, Nov 08, 2024 at 03:41:41PM -0500, Liam R. Howlett wrote:
> * Carlos Llamas <cmllamas@google.com> [241108 14:11]:
> > Allow multiple callers to install pages simultaneously by downgrading
> > the mmap_sem to non-exclusive mode.
>
> Since we actually allow downgrading of a lock, it would be more clear to
> say that you are changing from a read lock to a write lock. I was
> searching for the lock downgrade in this patch :)
ah, I can see how the wording here can be misleading. I'll rephrase that
to avoid confusion.
> > - ret = vm_insert_page(alloc->vma, addr, page);
> > - if (ret) {
> > + mmap_read_lock(alloc->mm);
>
> Ah, I debate bring this up, but you can do this without the mmap read
> lock. You can use rcu and the per-vma locking like in the page fault
> path. If you look at how that is done using the lock_vma_under_rcu()
> (mm/memory.c) then you can see that pages are installed today without
> the mmap locking (on some architectures - which includes x86_64 and
> arm64).
Right, per-vma locking is implemented in patch 7 of this series:
https://lore.kernel.org/all/20241108191057.3288442-8-cmllamas@google.com/
> userfaultfd had to do something like this as well, and created some
> abstraction to facilitate either mmap or rcu, based on the arch support.
> Going to rcu really helped performance there [1]. There was also a
> chance of the vma being missed, so it is checked again under the mmap
> read lock, but realistically that never happens and exists to ensure
> correctness.
hmm, if there are more users of this pattern in the future then perhaps
it might be worth adding a common helper?
> You also mention the shrinker and using the alloc->mutex, well zapping
> pages can also be done under the vma specific lock - if that helps?
>
> Freeing page tables is different though, that needs more locking, but I
> don't think this is an issue for you.
>
> [1]. https://lore.kernel.org/all/20240215182756.3448972-1-lokeshgidra@google.com/
ha, I was not aware of this. I'll have a look thanks.
>
> > + vma = vma_lookup(alloc->mm, addr);
>
> Thank you for not saving a pointer anymore.
lol, thanks to you for initiating this effort!
Cheers,
Carlos Llamas
next prev parent reply other threads:[~2024-11-08 22:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 19:10 [PATCH v3 0/8] binder: faster page installations Carlos Llamas
2024-11-08 19:10 ` [PATCH v3 1/8] Revert "binder: switch alloc->mutex to spinlock_t" Carlos Llamas
2024-11-08 19:10 ` [PATCH v3 2/8] binder: concurrent page installation Carlos Llamas
2024-11-08 20:41 ` Liam R. Howlett
2024-11-08 22:26 ` Carlos Llamas [this message]
2024-11-09 3:58 ` Liam R. Howlett
2024-11-12 11:10 ` David Hildenbrand
2024-11-12 14:43 ` Carlos Llamas
2024-11-12 14:53 ` David Hildenbrand
2024-11-12 15:15 ` Carlos Llamas
2024-11-08 19:10 ` [PATCH v3 3/8] binder: select correct nid for pages in LRU Carlos Llamas
2024-11-08 19:10 ` [PATCH v3 4/8] binder: remove struct binder_lru_page Carlos Llamas
2024-11-08 19:10 ` [PATCH v3 5/8] binder: replace alloc->vma with alloc->mapped Carlos Llamas
2024-11-08 19:10 ` [PATCH v3 6/8] binder: rename alloc->buffer to vm_start Carlos Llamas
2024-11-08 19:10 ` [PATCH v3 7/8] binder: use per-vma lock in page installation Carlos Llamas
2024-11-08 19:10 ` [PATCH v3 8/8] binder: propagate vm_insert_page() errors Carlos Llamas
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=Zy6QC71iEy3w5FYA@google.com \
--to=cmllamas@google.com \
--cc=Liam.Howlett@oracle.com \
--cc=arve@android.com \
--cc=brauner@kernel.org \
--cc=david@redhat.com \
--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 \
--cc=v-songbaohua@oppo.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.