On 14 Apr 2023 14:51:59 -0700 Suren Baghdasaryan <surenb@xxxxxxxxxx>
> On Fri, Apr 14, 2023 at 1:32=E2=80=AFPM Matthew Wilcox <willy@xxxxxxxxxxxxx=
> >
> > If we simply sleep waiting for the
> > I/O, we make any mmap() operation _which touches this VMA_ wait for
> > the I/O to complete. But I think that's OK, because new page faults
> > can continue to be serviced ... as long as they don't need to take
> > the mmap_lock.
>
> Ok, so we will potentially block VMA writers for the duration of the I/O...
> Stupid question: why was this a bigger problem for mmap_lock?
> Potentially our address space can consist of only one anon VMA, so
> locking that VMA vs mmap_lock should be the same from swap pagefault
> POV. Maybe mmap_lock is taken for write in some other important cases
> when VMA lock is not needed?
This question adds a churn to my mind then after searching the git more
than 30 minutes commit 89b15332af7c ("mm: drop mmap_sem before calling
balance_dirty_pages() in write fault") rises. And John can tell you
more about it.
