Re: [PATCH 1/1] Fix undefined reference to 'node_reclaim_distance'.

[Randy Dunlap]

On 12/23/19 8:42 AM, Matt Fleming wrote:
> On Mon, 16 Dec, at 02:50:49PM, Gonsolo wrote:
>>> The offending commit seems to be a55c7454a8c887b2 ("sched/topology:
>>> Improve load balancing on AMD EPYC systems").
>>>
>>> Probably the node_reclaim_distance variable should be moved from
>>> an SMP-specific file to a NUMA-specific file.
>>
>> There are two variables that are used elsewhere:
>>
>> int                             sched_max_numa_distance;
>>
>> Used in kernel/sched/fair.c and kernel/sched/topology.c. I would move
>> it to fair.c.
>>
>> int __read_mostly               node_reclaim_distance = RECLAIM_DISTANCE;
>>
>> Used in
>> arch/x86/kernel/cpu/amd.c, line 894
>> kernel/sched/topology.c
>> mm/khugepaged.c, line 725
>> mm/page_alloc.c, line 3529
>>
>> I'm not sure where to move this one.
> 
> Can someone test out this patch on one of the failing architectures?
> (sh, ppc64)

Yes, it fixes the arch/sh/ build errors in my testing.
I don't have a failing ppc64 .config file to test.

thanks.

> ---->8----
> 
> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
> index 6ec1e595b1d4..bf20e5883026 100644
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -1281,7 +1281,6 @@ static int			sched_domains_curr_level;
>  int				sched_max_numa_distance;
>  static int			*sched_domains_numa_distance;
>  static struct cpumask		***sched_domains_numa_masks;
> -int __read_mostly		node_reclaim_distance = RECLAIM_DISTANCE;
>  #endif
>  
>  /*
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 4785a8a2040e..733890d913ea 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3523,6 +3523,7 @@ bool zone_watermark_ok_safe(struct zone *z, unsigned int order,
>  }
>  
>  #ifdef CONFIG_NUMA
> +int __read_mostly		node_reclaim_distance = RECLAIM_DISTANCE;
>  static bool zone_allows_reclaim(struct zone *local_zone, struct zone *zone)
>  {
>  	return node_distance(zone_to_nid(local_zone), zone_to_nid(zone)) <=
> 


-- 
~Randy
Reported-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>