All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Muhammad Usama Anjum <usama.anjum@arm.com>
Cc: David Hildenbrand <david@kernel.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>,
	Brendan Jackman <jackmanb@google.com>,
	Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Nick Terrell <terrelln@fb.com>, David Sterba <dsterba@suse.com>,
	Vishal Moola <vishal.moola@gmail.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	bpf@vger.kernel.org, Ryan.Roberts@arm.com,
	david.hildenbrand@arm.com
Subject: Re: [PATCH v4 0/3] mm: Free contiguous order-0 pages efficiently
Date: Fri, 27 Mar 2026 12:42:49 -0700	[thread overview]
Message-ID: <20260327124249.a8de2259cf3438c5f4216894@linux-foundation.org> (raw)
In-Reply-To: <20260327125720.2270651-1-usama.anjum@arm.com>

On Fri, 27 Mar 2026 12:57:12 +0000 Muhammad Usama Anjum <usama.anjum@arm.com> wrote:

> A recent change to vmalloc caused some performance benchmark regressions (see
> [1]). I'm attempting to fix that (and at the same time significantly 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. While at it, optimize the
> __free_contig_frozen_range() as well.
> 
> Check that the contiguous range falls in the same section. If they aren't enabled,
> the if conditions get optimized out by the compiler as memdesc_section() returns 0.
> See num_pages_contiguous() for more details about it.

Thanks.  I'm seeing impressive speedups for microbenchmarks.  The
speedup in [3/3] may be a bit more real-worldy.

Do you have a feeling for how much difference these changes will make
for any real-world workload?

Also, AI review said things:
	https://sashiko.dev/#/patchset/20260327125720.2270651-1-usama.anjum@arm.com

The can_free one (at least) seems legit.  I suggest that can_free be
made local to that for() loop - this would clear things up a bit.

  parent reply	other threads:[~2026-03-27 19:42 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-27 12:57 [PATCH v4 0/3] mm: Free contiguous order-0 pages efficiently Muhammad Usama Anjum
2026-03-27 12:57 ` [PATCH v4 1/3] mm/page_alloc: Optimize free_contig_range() Muhammad Usama Anjum
2026-03-27 15:54   ` Zi Yan
2026-03-30 14:27   ` Vlastimil Babka (SUSE)
2026-03-31 13:51     ` Muhammad Usama Anjum
2026-03-30 14:30   ` Vlastimil Babka (SUSE)
2026-03-30 16:36     ` Muhammad Usama Anjum
2026-03-30 14:33   ` David Hildenbrand (Arm)
2026-03-31 13:52     ` Muhammad Usama Anjum
2026-03-27 12:57 ` [PATCH v4 2/3] vmalloc: Optimize vfree Muhammad Usama Anjum
2026-03-30 12:30   ` Uladzislau Rezki
2026-03-31 15:08     ` Muhammad Usama Anjum
2026-03-30 14:35   ` Vlastimil Babka (SUSE)
2026-03-31 15:09     ` Muhammad Usama Anjum
2026-03-30 14:38   ` David Hildenbrand (Arm)
2026-03-30 16:15     ` Muhammad Usama Anjum
2026-03-31 10:08       ` David Hildenbrand
2026-03-27 12:57 ` [PATCH v4 3/3] mm/page_alloc: Optimize __free_contig_frozen_range() Muhammad Usama Anjum
2026-03-27 15:54   ` Zi Yan
2026-03-30 14:36   ` Vlastimil Babka (SUSE)
2026-03-30 14:40   ` David Hildenbrand (Arm)
2026-03-30 14:41   ` David Hildenbrand (Arm)
2026-03-27 19:42 ` Andrew Morton [this message]
2026-03-30 11:27   ` [PATCH v4 0/3] mm: Free contiguous order-0 pages efficiently Muhammad Usama Anjum
2026-03-30 14:43   ` David Hildenbrand (Arm)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260327124249.a8de2259cf3438c5f4216894@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=Ryan.Roberts@arm.com \
    --cc=bpf@vger.kernel.org \
    --cc=david.hildenbrand@arm.com \
    --cc=david@kernel.org \
    --cc=dsterba@suse.com \
    --cc=hannes@cmpxchg.org \
    --cc=jackmanb@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=terrelln@fb.com \
    --cc=urezki@gmail.com \
    --cc=usama.anjum@arm.com \
    --cc=vbabka@kernel.org \
    --cc=vishal.moola@gmail.com \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.