On Fri, Sep 2, 2022 at 12:43 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > On Thu, Sep 01, 2022 at 10:34:48AM -0700, Suren Baghdasaryan wrote: > > This is a proof of concept for per-vma locks idea that was discussed > > during SPF [1] discussion at LSF/MM this year [2], which concluded with > > suggestion that “a reader/writer semaphore could be put into the VMA > > itself; that would have the effect of using the VMA as a sort of range > > lock. There would still be contention at the VMA level, but it would be an > > improvement.” This patchset implements this suggested approach. > > The whole reason I started the SPF thing waay back when was because one > of the primary reporters at the time had very large VMAs and a per-vma > lock wouldn't actually help anything at all. > > IIRC it was either scientific code initializing a huge matrix or a > database with a giant table; I'm sure the archives have better memory > than me. Regardless of the initial intent, SPF happens to be very useful for cases when we have multiple threads establishing some mappings concurrently with page faults (see details at [1]). Android vendors independently from each other were backporting your and Laurent's patchset for years. I found internal reports of similar mmap_lock contention issues in Google Fibers [2] and I suspect there are more places this happens if people looked closer. [1] https://lore.kernel.org/all/CAJuCfpE10y78SNPQ+LRY5EonDFhOG=1XjZ9FUUDiyhfhjZ54NA@xxxxxxxxxxxxxx/ [2] https://www.phoronix.com/scan.php?page=news_item&px=Google-Fibers-Toward-Open > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@xxxxxxxxxxx. >
