Hi, Yang, Yang Shi <yang.shi@xxxxxxxxxxxxxxxxx> writes: >>> diff -puN mm/vmscan.c~enable-numa-demotion mm/vmscan.c >>> --- a/mm/vmscan.c~enable-numa-demotion 2020-06-29 16:35:01.017312549 -0700 >>> +++ b/mm/vmscan.c 2020-06-29 16:35:01.023312549 -0700 >>> @@ -4165,9 +4165,10 @@ int node_reclaim_mode __read_mostly; >>> * These bit locations are exposed in the vm.zone_reclaim_mode sysctl >>> * ABI. New bits are OK, but existing bits can never change. >>> */ >>> -#define RECLAIM_RSVD (1<<0) /* (currently ignored/unused) */ >>> -#define RECLAIM_WRITE (1<<1) /* Writeout pages during reclaim */ >>> -#define RECLAIM_UNMAP (1<<2) /* Unmap pages during reclaim */ >>> +#define RECLAIM_RSVD (1<<0) /* (currently ignored/unused) */ >>> +#define RECLAIM_WRITE (1<<1) /* Writeout pages during reclaim */ >>> +#define RECLAIM_UNMAP (1<<2) /* Unmap pages during reclaim */ >>> +#define RECLAIM_MIGRATE (1<<3) /* Migrate pages during reclaim */ >>> /* >>> * Priority for NODE_RECLAIM. This determines the fraction of pages >> I found that RECLAIM_MIGRATE is defined but never referenced in the >> patch. >> >> If my understanding of the code were correct, shrink_do_demote_mapping() >> is called by shrink_page_list(), which is used by kswapd and direct >> reclaim. So as long as the persistent memory node is onlined, >> reclaim-based migration will be enabled regardless of node reclaim mode. > > It looks so according to the code. But the intention of a new node > reclaim mode is to do migration on reclaim *only when* the > RECLAIM_MODE is enabled by the users. > > It looks the patch just clear the migration target node masks if the > memory is offlined. > > So, I'm supposed you need check if node_reclaim is enabled before > doing migration in shrink_page_list() and also need make node reclaim > to adopt the new mode. But why shouldn't we migrate in kswapd and direct reclaim? I think that we may need a way to control it, but shouldn't disable it unconditionally. > Please refer to > https://lore.kernel.org/linux-mm/1560468577-101178-6-git-send-email-yang.shi@xxxxxxxxxxxxxxxxx/ > Best Regards, Huang, Ying