[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260105161741.3952456-1-ryan.roberts@arm.com>
Date: Mon, 5 Jan 2026 16:17:36 +0000
From: Ryan Roberts <ryan.roberts@....com>
To: Andrew Morton <akpm@...ux-foundation.org>,
David Hildenbrand <david@...nel.org>,
Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
Vlastimil Babka <vbabka@...e.cz>,
Mike Rapoport <rppt@...nel.org>,
Suren Baghdasaryan <surenb@...gle.com>,
Michal Hocko <mhocko@...e.com>,
Brendan Jackman <jackmanb@...gle.com>,
Johannes Weiner <hannes@...xchg.org>,
Zi Yan <ziy@...dia.com>,
Uladzislau Rezki <urezki@...il.com>,
"Vishal Moola (Oracle)" <vishal.moola@...il.com>
Cc: Ryan Roberts <ryan.roberts@....com>,
linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: [PATCH v1 0/2] Free contiguous order-0 pages efficiently
Hi All,
A recent change to vmalloc caused some performance benchmark regressions (see
[1]). I'm attempting to fix that (and at the same time signficantly improve
beyond the baseline) by freeing a contiguous set of order-0 pages as a batch.
At the same time I observed that free_contig_range() was essentially doing the
same thing as vfree() so I've fixed it there too.
I think I've convinced myself that free_pages_prepare() per order-0 page
followed by a single free_frozen_page_commit() or free_one_page() for the high
order block is safe/correct, but would be good if a page_alloc expert can
confirm!
Applies against today's mm-unstable (344d3580dacd). All mm selftests run and
pass.
Thanks,
Ryan
Ryan Roberts (2):
mm/page_alloc: Optimize free_contig_range()
vmalloc: Optimize vfree
include/linux/gfp.h | 1 +
mm/page_alloc.c | 116 +++++++++++++++++++++++++++++++++++++++-----
mm/vmalloc.c | 29 +++++++----
3 files changed, 125 insertions(+), 21 deletions(-)
--
2.43.0
Powered by blists - more mailing lists