From: Zi Yan <ziy@nvidia.com>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>,
David Hildenbrand <david@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 1/2] mm/numa: no task_numa_fault() call if page table is changed
Date: Thu, 08 Aug 2024 22:05:52 -0400 [thread overview]
Message-ID: <03D403CE-5893-456D-AB4B-67C9E9F0F532@nvidia.com> (raw)
In-Reply-To: <87cymizdvc.fsf@yhuang6-desk2.ccr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 7041 bytes --]
On 8 Aug 2024, at 21:25, Huang, Ying wrote:
> Kefeng Wang <wangkefeng.wang@huawei.com> writes:
>
>> On 2024/8/8 22:21, Zi Yan wrote:
>>> On 8 Aug 2024, at 10:14, David Hildenbrand wrote:
>>>
>>>> On 08.08.24 16:13, Zi Yan wrote:
>>>>> On 8 Aug 2024, at 4:22, David Hildenbrand wrote:
>>>>>
>>>>>> On 08.08.24 05:19, Baolin Wang wrote:
>>>>>>>
>>>>>>>
>> ...
>>>>>> Agreed, maybe we should simply handle that right away and replace the "goto out;" users by "return 0;".
>>>>>>
>>>>>> Then, just copy the 3 LOC.
>>>>>>
>>>>>> For mm/memory.c that would be:
>>>>>>
>>>>>> diff --git a/mm/memory.c b/mm/memory.c
>>>>>> index 67496dc5064f..410ba50ca746 100644
>>>>>> --- a/mm/memory.c
>>>>>> +++ b/mm/memory.c
>>>>>> @@ -5461,7 +5461,7 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
>>>>>> if (unlikely(!pte_same(old_pte, vmf->orig_pte))) {
>>>>>> pte_unmap_unlock(vmf->pte, vmf->ptl);
>>>>>> - goto out;
>>>>>> + return 0;
>>>>>> }
>>>>>> pte = pte_modify(old_pte, vma->vm_page_prot);
>>>>>> @@ -5528,15 +5528,14 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
>>>>>> vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd,
>>>>>> vmf->address, &vmf->ptl);
>>>>>> if (unlikely(!vmf->pte))
>>>>>> - goto out;
>>>>>> + return 0;
>>>>>> if (unlikely(!pte_same(ptep_get(vmf->pte), vmf->orig_pte))) {
>>>>>> pte_unmap_unlock(vmf->pte, vmf->ptl);
>>>>>> - goto out;
>>>>>> + return 0;
>>>>>> }
>>>>>> goto out_map;
>>>>>> }
>>>>>> -out:
>>>>>> if (nid != NUMA_NO_NODE)
>>>>>> task_numa_fault(last_cpupid, nid, nr_pages, flags);
>>>>>> return 0;
>>
>> Maybe drop this part too,
>>
>> diff --git a/mm/memory.c b/mm/memory.c
>> index 410ba50ca746..07343c1469e0 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -5523,6 +5523,7 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
>> if (!migrate_misplaced_folio(folio, vma, target_nid)) {
>> nid = target_nid;
>> flags |= TNF_MIGRATED;
>> + goto out;
>> } else {
>> flags |= TNF_MIGRATE_FAIL;
>> vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd,
>> @@ -5533,12 +5534,8 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
>> pte_unmap_unlock(vmf->pte, vmf->ptl);
>> return 0;
>> }
>> - goto out_map;
>> }
>>
>> - if (nid != NUMA_NO_NODE)
>> - task_numa_fault(last_cpupid, nid, nr_pages, flags);
>> - return 0;
>> out_map:
>> /*
>> * Make it present again, depending on how arch implements
>
> IMHO, migration success is normal path, while migration failure is error
> processing path. If so, it's better to use "goto" for error processing
> instead of normal path.
>
>> @@ -5551,6 +5548,7 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
>> numa_rebuild_single_mapping(vmf, vma, vmf->address,
>> vmf->pte,
>> writable);
>> pte_unmap_unlock(vmf->pte, vmf->ptl);
>> +out:
>> if (nid != NUMA_NO_NODE)
>> task_numa_fault(last_cpupid, nid, nr_pages, flags);
>> return 0;
>>
>>
How about calling task_numa_fault and return in the migration successful path?
(target_nid cannot be NUMA_NO_NODE, so if is not needed)
diff --git a/mm/memory.c b/mm/memory.c
index 3441f60d54ef..abdb73a68b80 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -5526,7 +5526,8 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
if (!migrate_misplaced_folio(folio, vma, target_nid)) {
nid = target_nid;
flags |= TNF_MIGRATED;
- goto out;
+ task_numa_fault(last_cpupid, nid, nr_pages, flags);
+ return 0;
} else {
flags |= TNF_MIGRATE_FAIL;
vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd,
@@ -5550,7 +5551,6 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
numa_rebuild_single_mapping(vmf, vma, vmf->address, vmf->pte,
writable);
pte_unmap_unlock(vmf->pte, vmf->ptl);
-out:
if (nid != NUMA_NO_NODE)
task_numa_fault(last_cpupid, nid, nr_pages, flags);
return 0;
Or move the make-present code inside migration failed branch? This one
does not duplicate code but others can jump into this branch.
diff --git a/mm/memory.c b/mm/memory.c
index 3441f60d54ef..c9b4e7099815 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -5526,7 +5526,6 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
if (!migrate_misplaced_folio(folio, vma, target_nid)) {
nid = target_nid;
flags |= TNF_MIGRATED;
- goto out;
} else {
flags |= TNF_MIGRATE_FAIL;
vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd,
@@ -5537,20 +5536,20 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
pte_unmap_unlock(vmf->pte, vmf->ptl);
return 0;
}
- }
out_map:
- /*
- * Make it present again, depending on how arch implements
- * non-accessible ptes, some can allow access by kernel mode.
- */
- if (folio && folio_test_large(folio))
- numa_rebuild_large_mapping(vmf, vma, folio, pte, ignore_writable,
- pte_write_upgrade);
- else
- numa_rebuild_single_mapping(vmf, vma, vmf->address, vmf->pte,
- writable);
- pte_unmap_unlock(vmf->pte, vmf->ptl);
-out:
+ /*
+ * Make it present again, depending on how arch implements
+ * non-accessible ptes, some can allow access by kernel mode.
+ */
+ if (folio && folio_test_large(folio))
+ numa_rebuild_large_mapping(vmf, vma, folio, pte,
+ ignore_writable, pte_write_upgrade);
+ else
+ numa_rebuild_single_mapping(vmf, vma, vmf->address,
+ vmf->pte, writable);
+ pte_unmap_unlock(vmf->pte, vmf->ptl);
+ }
+
if (nid != NUMA_NO_NODE)
task_numa_fault(last_cpupid, nid, nr_pages, flags);
return 0;
Of course, I will need to change mm/huge_memory.c as well.
Best Regards,
Yan, Zi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
next prev parent reply other threads:[~2024-08-09 2:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240807184730.1266736-1-ziy@nvidia.com>
[not found] ` <20240807184730.1266736-2-ziy@nvidia.com>
[not found] ` <8734nf1wil.fsf@yhuang6-desk2.ccr.corp.intel.com>
[not found] ` <4CC95A65-A183-4D7B-A52E-5AAFB56625E1@nvidia.com>
2024-08-08 23:13 ` [PATCH 2/2] mm/migrate: move common code to numa_migrate_check (was numa_migrate_prep) Zi Yan
[not found] ` <956553dc-587c-4a43-9877-7e8844f27f95@linux.alibaba.com>
[not found] ` <1881267a-723d-4ba0-96d0-d863ae9345a4@redhat.com>
[not found] ` <09AC6DFA-E50A-478D-A608-6EF08D8137E9@nvidia.com>
[not found] ` <052552f4-5a8d-4799-8f02-177585a1c8dd@redhat.com>
[not found] ` <8890DD6A-126A-406D-8AB9-97CF5A1F4DA4@nvidia.com>
[not found] ` <b0b94a65-51f1-459e-879f-696baba85399@huawei.com>
[not found] ` <6447AB19-CC4D-40C2-94F5-C39DE132E1D6@nvidia.com>
2024-08-08 15:12 ` [PATCH 1/2] mm/numa: no task_numa_fault() call if page table is changed Zi Yan
2024-08-09 1:25 ` Huang, Ying
2024-08-09 2:05 ` Zi Yan [this message]
2024-08-09 7:52 ` Huang, Ying
2024-08-09 13:28 ` Zi Yan
2024-08-09 13:49 ` David Hildenbrand
2024-08-09 14:17 ` Zi Yan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=03D403CE-5893-456D-AB4B-67C9E9F0F532@nvidia.com \
--to=ziy@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=stable@vger.kernel.org \
--cc=wangkefeng.wang@huawei.com \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox