[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAOFY-A3Z92AeGVCGFPe=8i6NJVoksPojuHO4hC+tOzpKiNBtUA@mail.gmail.com>
Date: Wed, 28 Jan 2026 20:44:52 -0800
From: Arjun Roy <arjunroy@...gle.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Brian Geffon <bgeffon@...gle.com>, Justin Green <greenjustin@...omium.org>,
akpm@...ux-foundation.org, linux-mm@...ck.org, david@...nel.org,
lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com, vbabka@...e.cz,
rppt@...nel.org, surenb@...gle.com, mhocko@...e.com,
linux-kernel@...r.kernel.org, greenjustin@...gle.com, rientjes@...gle.com
Subject: Re: [PATCH] mm: Refactor vma_map_pages to use vm_insert_pages
On Wed, Jan 28, 2026 at 4:51 PM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Wed, Jan 28, 2026 at 05:59:12PM -0500, Brian Geffon wrote:
> > On Wed, Jan 28, 2026 at 5:57 PM Justin Green <greenjustin@...omium.org> wrote:
> > >
> > > vma_map_pages currently calls vm_insert_page on each individual page in
> > > the mapping, which creates significant overhead because we are
> > > repeatedly spinlocking. Instead, we should batch insert pages using
> > > vm_insert_pages, which amortizes the cost of the spinlock.
> >
> > This makes sense, I wonder why this wasn't done previously?
>
> That's always a good question, because it might reveal why this patch is
> a bad idea ...
>
> However in this case, it simply seems to be an oversight.
> __vm_map_pages() was introduced in May 2019 and then vm_insert_pages()
> was added in April 2020.
>
Yes, it was an oversight. I had originally cooked up vm_insert_pages()
to amortize
that spinlock for TCP zerocopy receive, and had not noticed __vm_map_pages()
sitting right there.
Reviewed-by: Arjun Roy <arjunroy@...gle.com>
-Arjun
> Reviewed-by: Matthew Wilcox (Oracle) <willy@...radead.org>
Powered by blists - more mailing lists