Hi, Yang,
Yang Shi <yang.shi@xxxxxxxxxxxxxxxxx> writes:
But why shouldn't we migrate in kswapd and direct reclaim? I think thatIt looks so according to the code. But the intention of a new nodediff -puN mm/vmscan.c~enable-numa-demotion mm/vmscan.cI found that RECLAIM_MIGRATE is defined but never referenced in the
--- 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
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.
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.
we may need a way to control it, but shouldn't disable it
unconditionally.
Please refer toBest Regards,
https://lore.kernel.org/linux-mm/1560468577-101178-6-git-send-email-yang.shi@xxxxxxxxxxxxxxxxx/
Huang, Ying