Here is a follow-up that avoids the need for a BUILD_BUG_ON().
Pre-requisite: today's linux.git, plus Weizhao Ouyang's series v2, here:
https://lore.kernel.org/all/[email protected]/
Testing: I've done some cross-compile testing with various .config's, and
a short LTP test run. However, I have not yet attempted to verify the
actual reason strings during debugging.
I also noticed that migrate_mode is correctly passed around as an enum,
but migrate_reason is inaccurately passed around as an int. Not sure if
I'll follow up on that, as there is precious little (none, actually?)
type safety assistance from the compiler in discerning between an int
and an enum, so not much value in fixing it up.
Cc: Weizhao Ouyang <[email protected]>
Cc: "Huang, Ying" <[email protected]>
John Hubbard (1):
mm/migrate: de-duplicate migrate_reason strings
include/linux/migrate.h | 19 +------------------
include/linux/migrate_mode.h | 13 +++++++++++++
mm/debug.c | 20 +++++++++++---------
3 files changed, 25 insertions(+), 27 deletions(-)
--
2.33.0
In order to remove the need to manually keep three different files in
synch, provide a common definition of the mapping between enum
migrate_reason, and the associated strings for each enum item.
1. Use the tracing system's mapping of enums to strings, by redefining
and reusing the MIGRATE_REASON and supporting macros, and using that to
populate the string array in mm/debug.c.
2. Move enum migrate_reason to migrate_mode.h. This is not strictly
necessary for this patch, but migrate mode and migrate reason go
together, so this will slightly clarify things.
Cc: Weizhao Ouyang <[email protected]>
Cc: "Huang, Ying" <[email protected]>
Signed-off-by: John Hubbard <[email protected]>
---
include/linux/migrate.h | 19 +------------------
include/linux/migrate_mode.h | 13 +++++++++++++
mm/debug.c | 20 +++++++++++---------
3 files changed, 25 insertions(+), 27 deletions(-)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index c8077e936691..3d154fe03c96 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -19,24 +19,7 @@ struct migration_target_control;
*/
#define MIGRATEPAGE_SUCCESS 0
-/*
- * Keep sync with:
- * - macro MIGRATE_REASON in include/trace/events/migrate.h
- * - migrate_reason_names[MR_TYPES] in mm/debug.c
- */
-enum migrate_reason {
- MR_COMPACTION,
- MR_MEMORY_FAILURE,
- MR_MEMORY_HOTPLUG,
- MR_SYSCALL, /* also applies to cpusets */
- MR_MEMPOLICY_MBIND,
- MR_NUMA_MISPLACED,
- MR_CONTIG_RANGE,
- MR_LONGTERM_PIN,
- MR_DEMOTION,
- MR_TYPES
-};
-
+/* Defined in mm/debug.c: */
extern const char *migrate_reason_names[MR_TYPES];
#ifdef CONFIG_MIGRATION
diff --git a/include/linux/migrate_mode.h b/include/linux/migrate_mode.h
index 883c99249033..f37cc03f9369 100644
--- a/include/linux/migrate_mode.h
+++ b/include/linux/migrate_mode.h
@@ -19,4 +19,17 @@ enum migrate_mode {
MIGRATE_SYNC_NO_COPY,
};
+enum migrate_reason {
+ MR_COMPACTION,
+ MR_MEMORY_FAILURE,
+ MR_MEMORY_HOTPLUG,
+ MR_SYSCALL, /* also applies to cpusets */
+ MR_MEMPOLICY_MBIND,
+ MR_NUMA_MISPLACED,
+ MR_CONTIG_RANGE,
+ MR_LONGTERM_PIN,
+ MR_DEMOTION,
+ MR_TYPES
+};
+
#endif /* MIGRATE_MODE_H_INCLUDED */
diff --git a/mm/debug.c b/mm/debug.c
index fae0f81ad831..4333b6784a20 100644
--- a/mm/debug.c
+++ b/mm/debug.c
@@ -16,17 +16,19 @@
#include <linux/ctype.h>
#include "internal.h"
+#include <trace/events/migrate.h>
+
+/*
+ * Define EM() and EMe() so that MIGRATE_REASON from trace/events/migrate.h can
+ * be used to populate migrate_reason_names[].
+ */
+#undef EM
+#undef EMe
+#define EM(a, b) b,
+#define EMe(a, b) b
const char *migrate_reason_names[MR_TYPES] = {
- "compaction",
- "memory_failure",
- "memory_hotplug",
- "syscall_or_cpuset",
- "mempolicy_mbind",
- "numa_misplaced",
- "contig_range",
- "longterm_pin",
- "demotion",
+ MIGRATE_REASON
};
const struct trace_print_flags pageflag_names[] = {
--
2.33.0
On 2021/9/22 12:17, John Hubbard wrote:
> In order to remove the need to manually keep three different files in
> synch, provide a common definition of the mapping between enum
> migrate_reason, and the associated strings for each enum item.
>
> 1. Use the tracing system's mapping of enums to strings, by redefining
> and reusing the MIGRATE_REASON and supporting macros, and using that to
> populate the string array in mm/debug.c.
>
> 2. Move enum migrate_reason to migrate_mode.h. This is not strictly
> necessary for this patch, but migrate mode and migrate reason go
> together, so this will slightly clarify things.
>
> Cc: Weizhao Ouyang <[email protected]>
> Cc: "Huang, Ying" <[email protected]>
> Signed-off-by: John Hubbard <[email protected]>
> ---
> include/linux/migrate.h | 19 +------------------
> include/linux/migrate_mode.h | 13 +++++++++++++
> mm/debug.c | 20 +++++++++++---------
> 3 files changed, 25 insertions(+), 27 deletions(-)
LGTM.
And, maybe rename the migrate_mode.h?
Reviewed-by: Weizhao Ouyang <[email protected]>
Thanks,
Weizhao
On 9/21/21 22:53, Weizhao Ouyang wrote:
>
> On 2021/9/22 12:17, John Hubbard wrote:
>> In order to remove the need to manually keep three different files in
>> synch, provide a common definition of the mapping between enum
>> migrate_reason, and the associated strings for each enum item.
>>
>> 1. Use the tracing system's mapping of enums to strings, by redefining
>> and reusing the MIGRATE_REASON and supporting macros, and using that to
>> populate the string array in mm/debug.c.
>>
>> 2. Move enum migrate_reason to migrate_mode.h. This is not strictly
>> necessary for this patch, but migrate mode and migrate reason go
>> together, so this will slightly clarify things.
>>
>> Cc: Weizhao Ouyang <[email protected]>
>> Cc: "Huang, Ying" <[email protected]>
>> Signed-off-by: John Hubbard <[email protected]>
>> ---
>> include/linux/migrate.h | 19 +------------------
>> include/linux/migrate_mode.h | 13 +++++++++++++
>> mm/debug.c | 20 +++++++++++---------
>> 3 files changed, 25 insertions(+), 27 deletions(-)
>
> LGTM.
> And, maybe rename the migrate_mode.h?
>
I thought about this, and after failing to dream up a better
filename, just figured I'd leave it alone. But I'm open to suggestion
there. And it is easy to change, since it's only included from two
places.
> Reviewed-by: Weizhao Ouyang <[email protected]>
Thanks for the review!
thanks,
--
John Hubbard
NVIDIA