Re: [PATCH 0/5] Page demotion for memory reclaim

> Yes, we may not want to migrate everything in the shrink_page_list() > pages. We might want to keep a page, so we have to do those checks first. At > the point we know we want to attempt migration, the page is already > locked and not in a list, so it is just easier to directly invoke the > new __unmap_and_move_locked() that migrate_pages() eventually also calls. Right, I understand that you want to only migrate small pages to begin with. My question is why not using the existing migrate_pages() in your patch 3. Like: diff --git a/mm/vmscan.c b/mm/vmscan.c index a5ad0b35ab8e..0a0753af357f 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1261,6 +1261,20 @@ static unsigned long shrink_page_list(struct list_head *page_list, ; /* try to reclaim the page below */ } + if (!PageCompound(page)) { + int next_nid = next_migration_node(page); + int err; + + if (next_nid != TERMINAL_NODE) { + LIST_HEAD(migrate_list); + list_add(&migrate_list, &page->lru); + err = migrate_pages(&migrate_list, alloc_new_node_page, NULL, + next_nid, MIGRATE_ASYNC, MR_DEMOTION); + if (err) + putback_movable_pages(&migrate_list); + } + } + /* * Anonymous process memory has backing store? * Try to allocate it some swap space here. Because your new migrate_demote_mapping() basically does the same thing as the code above. If you are not OK with the gfp flags in alloc_new_node_page(), you can just write your own alloc_new_node_page(). :)