[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aPaQNYsN_YPDOwQG@gourry-fedora-PF4VCD3F>
Date: Mon, 20 Oct 2025 15:40:37 -0400
From: Gregory Price <gourry@...rry.net>
To: David Hildenbrand <david@...hat.com>
Cc: Zi Yan <ziy@...dia.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, kernel-team@...a.com,
akpm@...ux-foundation.org, vbabka@...e.cz, surenb@...gle.com,
mhocko@...e.com, jackmanb@...gle.com, hannes@...xchg.org
Subject: Re: [RFC PATCH] page_alloc: allow migration of smaller hugepages
during contig_alloc.
On Mon, Oct 20, 2025 at 09:18:36PM +0200, David Hildenbrand wrote:
> >
> > Basically, what is the right way of checking a folio order without lock?
> > Should we have a standardized helper function for that?
>
> As raised, snapshot_page() tries to stabilize the folio best it can.
is snapshot_page() even worth it if we're already racing on flag checks?
i.e. there's already a race condition between
pfn_range_valid_contig(range) -> compaction(range)
on some bogus value the worst that happens is either compaction gets
called when it can't compact, or compaction doesn't get called when it
could compact - either way, compaction still handles it if called.
We may just skip some blocks (which is still better than now).
--
on compound_order - from mm.h:
/*
* compound_order() can be called without holding a reference, which means
* that niceties like page_folio() don't work. These callers should be
* prepared to handle wild return values. For example, PG_head may be
* set before the order is initialised, or this may be a tail page.
* See compaction.c for some good examples.
*/
Seems like the correct interface given the scenario. I'll poke around.
~Gregory
Powered by blists - more mailing lists