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.
