[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f32f51f9-d73f-436e-942d-f14e010fe29d@linux.ibm.com>
Date: Sun, 29 Dec 2024 20:19:35 +0530
From: Donet Tom <donettom@...ux.ibm.com>
To: Gregory Price <gourry@...rry.net>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org, nehagholkar@...a.com,
abhishekd@...a.com, kernel-team@...a.com, david@...hat.com,
nphamcs@...il.com, akpm@...ux-foundation.org, hannes@...xchg.org,
kbusch@...a.com, ying.huang@...ux.alibaba.com
Subject: Re: [RFC v2 PATCH 2/5] memory: move conditionally defined enums use
inside ifdef tags
On 12/27/24 21:12, Gregory Price wrote:
> On Fri, Dec 27, 2024 at 04:04:05PM +0530, Donet Tom wrote:
>> On 12/11/24 03:07, Gregory Price wrote:
>>> NUMA_HINT_FAULTS and NUMA_HINT_FAULTS_LOCAL are only defined if
>>> CONFIG_NUMA_BALANCING is defined, but are used outside the tags in
>>> numa_migrate_check(). Fix this.
>>>
>>> TNF_SHARED is only used if CONFIG_NUMA_BALANCING is enabled, so
>>> moving this line inside the ifdef is also safe - despite use of TNF_*
>>> elsewhere in the function. TNF_* are not conditionally defined.
>>>
>>> Signed-off-by: Gregory Price <gourry@...rry.net>
>>> ---
>>> mm/memory.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/mm/memory.c b/mm/memory.c
>>> index 83fd35c034d7..6ad7616918c4 100644
>>> --- a/mm/memory.c
>>> +++ b/mm/memory.c
>>> @@ -5573,14 +5573,14 @@ int numa_migrate_check(struct folio *folio, struct vm_fault *vmf,
>>> /* Record the current PID acceesing VMA */
>>> vma_set_access_pid_bit(vma);
>>> - count_vm_numa_event(NUMA_HINT_FAULTS);
>>> #ifdef CONFIG_NUMA_BALANCING
>> IIUC,|do_huge_pmd_numa_page|() and|do_numa_page()| are executed only if
>> |CONFIG_NUMA_BALANCING| is enabled (|pte_protnone()| and|pmd_protnone()|
>> return 0 if|CONFIG_NUMA_BALANCING| is disabled).
>>
>> Given this, do we still need the|#ifdef|?
>>
> the NUMA_HINT_FAULTS stuff is only defined if CONFIG_NUMA_BALANCING is
> built.
>
> The ifdefs around some of this code is a bit inconsistent, it's
> probably worth a separate line to try to clean it up.
Sure. Thank you.
>
> ~Gregory
Powered by blists - more mailing lists