Re: [PATCH v2 2/2] mm/debug: sync up latest migrate_reason to migrate_reason_names

[Huang, Ying]

Weizhao Ouyang <o451686892@xxxxxxxxx> writes:

> On 2021/9/21 15:07, Huang, Ying wrote:
>> Weizhao Ouyang <o451686892@xxxxxxxxx> writes:
>>
>>> Sync up MR_DEMOTION to migrate_reason_names and add a synch prompt.
>>>
>>> Fixes: 26aa2d199d6f ("mm/migrate: demote pages during reclaim")
>>> Signed-off-by: Weizhao Ouyang <o451686892@xxxxxxxxx>
>>> Reviewed-by: "Huang, Ying" <ying.huang@xxxxxxxxx>
>>> ---
>>>  include/linux/migrate.h | 6 +++++-
>>>  mm/debug.c              | 1 +
>>>  2 files changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/linux/migrate.h b/include/linux/migrate.h
>>> index 326250996b4e..c8077e936691 100644
>>> --- a/include/linux/migrate.h
>>> +++ b/include/linux/migrate.h
>>> @@ -19,6 +19,11 @@ 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,
>>> @@ -32,7 +37,6 @@ enum migrate_reason {
>>>  	MR_TYPES
>>>  };
>>>  
>>> -/* In mm/debug.c; also keep sync with include/trace/events/migrate.h */
>>>  extern const char *migrate_reason_names[MR_TYPES];
>>>  
>>>  #ifdef CONFIG_MIGRATION
>>> diff --git a/mm/debug.c b/mm/debug.c
>>> index e61037cded98..fae0f81ad831 100644
>>> --- a/mm/debug.c
>>> +++ b/mm/debug.c
>>> @@ -26,6 +26,7 @@ const char *migrate_reason_names[MR_TYPES] = {
>>>  	"numa_misplaced",
>>>  	"contig_range",
>>>  	"longterm_pin",
>>> +	"demotion",
>>>  };
>>>  
>>>  const struct trace_print_flags pageflag_names[] = {
>> Can we add BUILD_BUG_ON() somewhere to capture at least some
>> synchronization issue?
>
> Hi Huang, we discussed this in the v1 thread with you and John, seems you
> missed it. Now we just add a comment to do the synchronization, and we can
> figure out a more general way to use strings which in trace_events straight.

Got it!  And I think we can add the BUILD_BUG_ON() now and delete it
when we have a better solution to deal with that.  But if you can work
out a better solution quickly, that's fine to ignore this.

Best Regards,
Huang, Ying