Re: [RFC PATCH 00/31] Generating physically contiguous memory after page allocation
From: Zi Yan
Date: Tue Feb 19 2019 - 21:33:40 EST
On 19 Feb 2019, at 17:42, Mike Kravetz wrote:
On 2/15/19 2:08 PM, Zi Yan wrote:
Thanks for working on this issue!
I have not yet had a chance to take a look at the code. However, I do
some general questions/comments on the approach.
Thanks for replying. The code is very intrusive and has a lot of hacks,
so it is
OK for us to discuss the general idea first. :)
The patchset I developed to generate physically contiguous
sized pages merely moves pages around. There are three components in
1) a new page migration mechanism, called exchange pages, that
content of two in-use pages instead of performing two back-to-back
migration. It saves on overheads and avoids page reclaim and memory
in the page allocation path, although it is not strictly required if
free memory is available in the system.
2) a new mechanism that utilizes both page migration and exchange
produce physically contiguous memory/arbitrary sized pages without
any new pages, unlike what khugepaged does. It works on per-VMA
physically contiguous memory out of each VMA, which is virtually
A simple range tree is used to ensure no two VMAs are overlapping
other in the physical address space.
This appears to be a new approach to generating contiguous areas.
attempts had relied on finding a contiguous area that can then be used
various purposes including user mappings. Here, you take an existing
and make it contiguous. [RFC PATCH 04/31] mm: add mem_defrag
talks about creating a (VPN, PFN) anchor pair for each vma and then
this pair as the base for creating a contiguous area.
I'm curious, how 'fixed' is the anchor? As you know, there could be a
non-movable page in the PFN range. As a result, you will not be able
create a contiguous area starting at that PFN. In such a case, do we
another PFN? I know this could result in much page shuffling. I'm
trying to figure out how we satisfy a user who really wants a
area. Is there some method to keep trying?
Good question. The anchor is determined on a per-VMA basis, which can be
but in this patchiest, I used a very simple strategy â making all VMAs
in the physical address space to get maximum overall contiguity and not
even if non-moveable pages are encountered when generating physically
Basically, first VMA1 in the virtual address space has its anchor as
second VMA1 has its anchor as (VMA2_start_VPN, ZONE_start_PFN +
VMA1_size), and so on.
This makes all VMA not overlapping in physical address space during
generation. When there is a non-moveable page, the anchor will not be
no matter whether we assign a new anchor or not, the contiguous pages
the non-moveable page. If we are trying to get a new anchor, more effort
is needed to
avoid overlapping new anchor with existing contiguous pages. Any
nullify the existing contiguous pages.
To satisfy a user who wants a contiguous area with N pages, the minimal
any two non-moveable pages should be bigger than N pages in the system
nothing would work. If there is such an area (PFN1, PFN1+N) in the
physical address space,
you can set the anchor to (VPN_USER, PFN1) and use exchange_pages() to
generate a contiguous
area with N pages. Instead, alloc_contig_pages(PFN1, PFN1+N, â) could
also work, but
only at page allocation time. It also requires the system has N free
alloc_contig_pages() are migrating the pages in (PFN1, PFN1+N) away, or
you need to swap
pages to make the space.
Let me know if this makes sense to you.