From: "Huang, Ying" <ying.huang@intel.com>
To: Zi Yan <ziy@nvidia.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: Fri, 09 Aug 2024 15:52:22 +0800 [thread overview]
Message-ID: <874j7uyvyh.fsf@yhuang6-desk2.ccr.corp.intel.com> (raw)
In-Reply-To: <03D403CE-5893-456D-AB4B-67C9E9F0F532@nvidia.com> (Zi Yan's message of "Thu, 08 Aug 2024 22:05:52 -0400")
Zi Yan <ziy@nvidia.com> writes:
> 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;
>
This looks better for me, or change it further.
if (migrate_misplaced_folio(folio, vma, target_nid))
goto out_map_pt;
nid = target_nid;
flags |= TNF_MIGRATED;
task_numa_fault(last_cpupid, nid, nr_pages, flags);
return 0;
out_map_pt:
flags |= TNF_MIGRATE_FAIL;
vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd,
...
>
>
> 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,
Huang, Ying
next prev parent reply other threads:[~2024-08-09 7:56 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
2024-08-09 7:52 ` Huang, Ying [this message]
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=874j7uyvyh.fsf@yhuang6-desk2.ccr.corp.intel.com \
--to=ying.huang@intel.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=ziy@nvidia.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