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? > 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
