[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aPevZplPtDUPZFUn@gourry-fedora-PF4VCD3F>
Date: Tue, 21 Oct 2025 12:05:58 -0400
From: Gregory Price <gourry@...rry.net>
To: David Hildenbrand <david@...hat.com>
Cc: 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,
ziy@...dia.com
Subject: Re: [RFC PATCH v2] page_alloc: allow migration of smaller hugepages
during contig_alloc.
On Tue, Oct 21, 2025 at 11:30:48AM +0200, David Hildenbrand wrote:
> > Compaction `isolate_migrate_pages_block()` already expects requests
>
> Please, let's not talk about "compaction" here, it's just confusing to talk
> about compaction for something that is not compaction but uses some
> primitives (because not properly separated yet)
>
> Just say "isolate_migrate_pages_block() already expects ..."
>
will do
> > + /* Don't consider moving same size/larger pages */
> > + page = compound_head(page);
> > + order = compound_order(page);
> > + if ((order >= MAX_PAGE_ORDER) ||
> > + (nr_pages < (1 << order)))
> > + return false;
>
> This is roughly what we do in pageblock_skip_persistent(), just with a
> hardcoded pageblock size.
>
> I'm not sure about the MAX_PAGE_ORDER check, though. If an arch supports two
> hugetlb sizes that exceed MAX_PAGE_ORDER, it would not work as expected.
>
> Doesn't arm64 support that with cont-PMD vs. PUD hugetlb folios?
> MAX_FOLIO_ORDER would be better.
Will adjust to MAX_FOLIO_ORDER, makes sense. Missed that. Will take a
look at the pageblock code, I think I was looking at the compaction and
some other code for inspiration here.
~Gregory
Powered by blists - more mailing lists