From: Carlos Llamas <cmllamas@google.com>
To: Hillf Danton <hdanton@sina.com>
Cc: linux-kernel@vger.kernel.org,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Suren Baghdasaryan <surenb@google.com>
Subject: Re: [PATCH 8/8] binder: use per-vma lock in page installation
Date: Thu, 7 Nov 2024 03:23:01 +0000 [thread overview]
Message-ID: <ZywylcwmJFiVvkhb@google.com> (raw)
In-Reply-To: <20241106225534.3388-1-hdanton@sina.com>
On Thu, Nov 07, 2024 at 06:55:34AM +0800, Hillf Danton wrote:
> On Tue, 5 Nov 2024 20:02:50 +0000 Carlos Llamas <cmllamas@google.com>
> > Use per-vma locking for concurrent page installations, this minimizes
> > contention with unrelated vmas improving performance. The mmap_lock is
> > still acquired when needed though, e.g. before folio_walk_start().
> >
> Is the locking order correct in this patch?
>
> lock vma
> lock vma->vm_mm
Sorry, I've also fixed this issue in v2.
I was trying to avoid having to vma_lookup() again after switching
locks. However, this seems unavoidable so I've fixed the locking order
and I've also switched to get_user_pages_remote(). This seems like a
better option now.
--
Carlos Llamas
prev parent reply other threads:[~2024-11-07 3:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-05 20:02 [PATCH 0/8] binder: faster page installations Carlos Llamas
2024-11-05 20:02 ` [PATCH 1/8] Revert "binder: switch alloc->mutex to spinlock_t" Carlos Llamas
2024-11-05 20:02 ` [PATCH 2/8] binder: concurrent page installation Carlos Llamas
2024-11-05 20:02 ` [PATCH 3/8] binder: select correct nid for pages in LRU Carlos Llamas
2024-11-05 20:02 ` [PATCH 4/8] binder: remove struct binder_lru_page Carlos Llamas
2024-11-05 20:02 ` [PATCH 5/8] binder: use alloc->mapped to save the vma state Carlos Llamas
2024-11-05 20:02 ` [PATCH 6/8] binder: remove cached alloc->vma pointer Carlos Llamas
2024-11-05 20:02 ` [PATCH 7/8] binder: rename alloc->buffer to vm_start Carlos Llamas
2024-11-05 20:02 ` [PATCH 8/8] binder: use per-vma lock in page installation Carlos Llamas
2024-11-05 21:44 ` Carlos Llamas
2024-11-06 22:55 ` Hillf Danton
2024-11-07 3:23 ` 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=ZywylcwmJFiVvkhb@google.com \
--to=cmllamas@google.com \
--cc=hdanton@sina.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=surenb@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.