[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aPZ0OKx_VnQ4H_w1@gourry-fedora-PF4VCD3F>
Date: Mon, 20 Oct 2025 13:41:12 -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] page_alloc: allow migration of smaller hugepages
during contig_alloc.
On Mon, Oct 20, 2025 at 07:24:04PM +0200, David Hildenbrand wrote:
> On 20.10.25 19:06, Gregory Price wrote:
>
> Do we really need the folio_hugetlb_migratable() check?
> This code is completely racy.
My thought was it's better to check if any *one* folio in the bunch is
non-migratable, it's better to never even call compaction in the first
place. But you're right, this is racy.
In one race, the compaction code will just fail if this bit gets set
between now and the isolate call in folio_isolate_hugetlb() - resulting
in searching the next block anyway. So that seemed ok?
In the other race, the bit becomes un-set and we skip a block that might
otherwise be valid.
I can drop this check, it's just an optimistic optimization anyway.
I should also probably check CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION here
regardless, since we should skip compaction if migration isn't possible.
>> folio_nr_pages() should be fine AFAIKT (no
> VM_WARN_ON() etc), not sure about folio_test_hugetlb_migratable().
will change, and will check/change based on above thoughts.
~Gregory
Powered by blists - more mailing lists