Re: [PATCH] docs/mm: add VMA locks documentation

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Mon, Nov 11, 2024 at 02:42:44AM +0000, Wei Yang wrote:

> >+Read locks are acquired via :c:func:`!vma_start_read`, which is an optimistic
> >+operation, i.e. it tries to acquire a read lock but returns false if it is
> >+unable to do so. At the end of the read operation, :c:func:`!vma_end_read` is
> >+called to release the VMA read lock. This can be done under RCU alone.
> >+
> >+Writing requires the mmap to be write-locked and the VMA lock to be acquired via
> >+:c:func:`!vma_start_write`, however the write lock is released by the termination or
> >+downgrade of the mmap write lock so no :c:func:`!vma_end_write` is required.
> >+
> >+All this is achieved by the use of per-mm and per-VMA sequence counts, which are
> >+used in order to reduce complexity, especially for operations which write-lock
> >+multiple VMAs at once.
> >+
>
> Hi, Lorenzo
>
> I got a question more than a comment when trying to understand the mechanism.
p>
> I am thinking about the benefit of PER_VMA_LOCK.
>
> For write, we always need to grab mmap_lock w/o PER_VMA_LOCK.
> For read, seems we don't need to grab mmap_lock with PER_VMA_LOCK. So read
> operation benefit the most with PER_VMA_LOCK, right?

Yes this is the point of it, VMA fields are read-mostly and the most natural use
for this is page faulting.

The whole intent is to allow for the read lock under RCU.