On 09/22/22 16:27, Doug Berger wrote: > On 9/22/2022 3:41 PM, Mike Kravetz wrote: > > On 09/22/22 13:25, Mike Kravetz wrote: > > > On 09/21/22 15:36, Doug Berger wrote: > > > > > > As noted above, for pages to be migrated we first try to use an existing > > > free huge page as the target. Quite some time ago, Michal added code to > > > allocate a new page from buddy as the target if no free huge pages were > > > available. This change also included a special flag to dissolve the > > > source huge page when it is freed. It seems like this is the exact > > > behavior we want here? I wonder if it might be easier just to use this > > > existing code? > > > > Totally untested, but I believe the patch below would accomplish this. > > > > From aa8fc11bb67bc9e67e3b6b280fab339afce37759 Mon Sep 17 00:00:00 2001 > > From: Mike Kravetz <mike.kravetz@xxxxxxxxxx> > > Date: Thu, 22 Sep 2022 15:32:10 -0700 > > Subject: [PATCH] hugetlb: force alloc_contig_range hugetlb migrations to > > allocate new pages > > > > When migrating hugetlb pages as the result of an alloc_contig_range > > operation, allocate a new page from buddy for the migration target. > > This guarantees that the number of hugetlb pages is not decreased by > > the operation. In addition, this will result in the special HPageTemporary > > flag being set in the source page so that it will be dissolved when > > freed. > > <snip> > I believe I exposed alloc_migrate_huge_page() and conditionally invoked it > from alloc_migration_target() when in alloc_contig, which is roughly > equivalent. I didn't consider modifying the mtc to pass the information so > my logic in alloc_migration_target() was a little kludgy. > > Like I said, this can be made to work and I'm happy to accept an alternative > if others agree. I think the isolation test of patch 3 is also still > desirable. Yes, hoping to get some other opinions as well. I do agree that patch 3 is still a good idea. -- Mike Kravetz
