[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJuCfpEreo5vKwKU1Qs1nXe50daGN-yaPz5v4BS7Y08no7sjiA@mail.gmail.com>
Date: Fri, 2 Sep 2022 07:45:53 -0700
From: Suren Baghdasaryan <surenb@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Michel Lespinasse <michel@...pinasse.org>,
Jerome Glisse <jglisse@...gle.com>,
Michal Hocko <mhocko@...e.com>,
Vlastimil Babka <vbabka@...e.cz>,
Johannes Weiner <hannes@...xchg.org>,
Mel Gorman <mgorman@...e.de>,
Davidlohr Bueso <dave@...olabs.net>,
Matthew Wilcox <willy@...radead.org>,
"Liam R. Howlett" <liam.howlett@...cle.com>,
Laurent Dufour <ldufour@...ux.ibm.com>,
Laurent Dufour <laurent.dufour@...ibm.com>,
"Paul E . McKenney" <paulmck@...nel.org>,
Andy Lutomirski <luto@...nel.org>,
Song Liu <songliubraving@...com>, Peter Xu <peterx@...hat.com>,
David Hildenbrand <david@...hat.com>, dhowells@...hat.com,
Hugh Dickins <hughd@...gle.com>, bigeasy@...utronix.de,
Kent Overstreet <kent.overstreet@...ux.dev>,
David Rientjes <rientjes@...gle.com>,
Axel Rasmussen <axelrasmussen@...gle.com>,
Joel Fernandes <joelaf@...gle.com>,
Minchan Kim <minchan@...gle.com>,
kernel-team <kernel-team@...roid.com>,
linux-mm <linux-mm@...ck.org>,
linux-arm-kernel@...ts.infradead.org,
linuxppc-dev@...ts.ozlabs.org, x86@...nel.org,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH RESEND 00/28] per-VMA locks proposal
On Fri, Sep 2, 2022 at 12:43 AM Peter Zijlstra <peterz@...radead.org> 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@mail.gmail.com/
[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@...roid.com.
>
Powered by blists - more mailing lists