On Fri, Jan 29, 2021 at 6:29 AM Oscar Salvador <osalvador@xxxxxxx> wrote: > > On Wed, Jan 27, 2021 at 11:36:15AM +0100, David Hildenbrand wrote: > > Extending on that, I just discovered that only x86-64, ppc64, and arm64 > > really support hugepage migration. > > > > Maybe one approach with the "magic switch" really would be to disable > > hugepage migration completely in hugepage_migration_supported(), and > > consequently making hugepage_movable_supported() always return false. > > Ok, so migration would not fork for these pages, and since them would > lay in !ZONE_MOVABLE there is no guarantee we can unplug the memory. > Well, we really cannot unplug it unless the hugepage is not used > (it can be dissolved at least). > > Now to the allocation-when-freeing. > Current implementation uses GFP_ATOMIC(or wants to use) + forever loop. > One of the problems I see with GFP_ATOMIC is that gives you access > to memory reserves, but there are more users using those reserves. > Then, worst-scenario case we need to allocate 16MB order-0 pages > to free up 1GB hugepage, so the question would be whether reserves > really scale to 16MB + more users accessing reserves. > > As I said, if anything I would go for an optimistic allocation-try > , if we fail just refuse to shrink the pool. > User can always try to shrink it later again via /sys interface. Yeah. It seems that this is the easy way to move on. Thanks. > > Since hugepages would not be longer in ZONE_MOVABLE/CMA and are not > expected to be migratable, is that ok? > > Using the hugepage for the vmemmap array was brought up several times, > but that would imply fragmenting memory over time. > > All in all seems to be overly complicated (I might be wrong). > > > > Huge pages would never get placed onto ZONE_MOVABLE/CMA and cannot be > > migrated. The problem I describe would apply (careful with using > > ZONE_MOVABLE), but well, it can at least be documented. > > I am not a page allocator expert but cannot the allocation fallback > to ZONE_MOVABLE under memory shortage on other zones? > > > -- > Oscar Salvador > SUSE L3
