On 09/10/2023 16:52, Zi Yan wrote: > (resent as plain text) > On 9 Oct 2023, at 10:10, Ryan Roberts wrote: > >> On 09/10/2023 14:24, Zi Yan wrote: >>> On 2 Oct 2023, at 8:32, Ryan Roberts wrote: >>> >>>> Hi Zi, >>>> >>>> On 12/09/2023 17:28, Zi Yan wrote: >>>>> From: Zi Yan <ziy@xxxxxxxxxx> >>>>> >>>>> Hi all, >>>>> >>>>> This patchset enables >0 order folio memory compaction, which is one of >>>>> the prerequisitions for large folio support[1]. It is on top of >>>>> mm-everything-2023-09-11-22-56. >>>> >>>> I've taken a quick look at these and realize I'm not well equipped to provide >>>> much in the way of meaningful review comments; All I can say is thanks for >>>> putting this together, and yes, I think it will become even more important for >>>> my work on anonymous large folios. >>>> >>>> >>>>> >>>>> Overview >>>>> === >>>>> >>>>> To support >0 order folio compaction, the patchset changes how free pages used >>>>> for migration are kept during compaction. Free pages used to be split into >>>>> order-0 pages that are post allocation processed (i.e., PageBuddy flag cleared, >>>>> page order stored in page->private is zeroed, and page reference is set to 1). >>>>> Now all free pages are kept in a MAX_ORDER+1 array of page lists based >>>>> on their order without post allocation process. When migrate_pages() asks for >>>>> a new page, one of the free pages, based on the requested page order, is >>>>> then processed and given out. >>>>> >>>>> >>>>> Optimizations >>>>> === >>>>> >>>>> 1. Free page split is added to increase migration success rate in case >>>>> a source page does not have a matched free page in the free page lists. >>>>> Free page merge is possible but not implemented, since existing >>>>> PFN-based buddy page merge algorithm requires the identification of >>>>> buddy pages, but free pages kept for memory compaction cannot have >>>>> PageBuddy set to avoid confusing other PFN scanners. >>>>> >>>>> 2. Sort source pages in ascending order before migration is added to >>>>> reduce free page split. Otherwise, high order free pages might be >>>>> prematurely split, causing undesired high order folio migration failures. >>>> >>>> Not knowing much about how compaction actually works, naively I would imagine >>>> that if you are just trying to free up a known amount of contiguous physical >>>> space, then working through the pages in PFN order is more likely to yield the >>>> result quicker? Unless all of the pages in the set must be successfully migrated >>>> in order to free up the required amount of space... >>> >>> During compaction, pages are not freed, since that is the job of page reclaim. >> >> Sorry yes - my fault for using sloppy language. When I said "free up a known >> amount of contiguous physical space", I really meant "move pages in order to >> recover an amount of contiguous physical space". But I still think the rest of >> what I said applies; wouldn't you be more likely to reach your goal quicker if >> you sort by PFN? > > Not always. If the in-use folios on the left are order-2, order-2, order-4 > (all contiguous in one pageblock) and free pages on the right are order-4 (pageblock N), > order-2, order-2 (pageblock N-1) and it is not a single order-8, since there are > in-use folios in the middle), going in PFN order will not get you an order-8 free > page, since first order-4 free page will be split into two order-2 for the first > two order-2 in-use folios. But if you migrate in the the descending order of > in-use page orders, you can get an order-8 free page at the end. > > The patchset minimizes free page splits to avoid the situation described above, > since once a high order free page is split, the opportunity of migrating a high order > in-use folio into it is gone and hardly recoverable. OK I get it now - thanks! > > >>> The goal of compaction is to get a high order free page without freeing existing >>> pages to avoid potential high cost IO operations. If compaction does not work, >>> page reclaim would free pages to get us there (and potentially another follow-up >>> compaction). So either pages are migrated or stay where they are during compaction. >>> >>> BTW compaction works by scanning in use pages from lower PFN to higher PFN, >>> and free pages from higher PFN to lower PFN until two scanners meet in the middle. >>> >>> -- >>> Best Regards, >>> Yan, Zi > > > Best Regards, > Yan, Zi
