All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] mm: add access/dirty bit on numa page fault
@ 2022-03-17  6:50 Bibo Mao
  2022-03-17 12:23 ` Matthew Wilcox
  2022-03-17 12:32 ` David Hildenbrand
  0 siblings, 2 replies; 9+ messages in thread
From: Bibo Mao @ 2022-03-17  6:50 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-mm, linux-kernel, Anshuman Khandual

On platforms like x86/arm which supports hw page walking, access
and dirty bit is set by hw, however on some platforms without
such hw functions, access and dirty bit is set by software in
next trap.

During numa page fault, dirty bit can be added for old pte if
fail to migrate on write fault. And if it succeeds to migrate,
access bit can be added for migrated new pte, also dirty bit
can be added for write fault.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
---
 mm/memory.c | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/mm/memory.c b/mm/memory.c
index c125c4969913..65813bec9c06 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4404,6 +4404,22 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
 	if (migrate_misplaced_page(page, vma, target_nid)) {
 		page_nid = target_nid;
 		flags |= TNF_MIGRATED;
+
+		/*
+		 * update pte entry with access bit, and dirty bit for
+		 * write fault
+		 */
+		spin_lock(vmf->ptl);
+		pte = *vmf->pte;
+		pte = pte_mkyoung(pte);
+		if (was_writable) {
+			pte = pte_mkwrite(pte);
+			if (vmf->flags & FAULT_FLAG_WRITE)
+				pte = pte_mkdirty(pte);
+		}
+		set_pte_at(vma->vm_mm, vmf->address, vmf->pte, pte);
+		update_mmu_cache(vma, vmf->address, vmf->pte);
+		pte_unmap_unlock(vmf->pte, vmf->ptl);
 	} else {
 		flags |= TNF_MIGRATE_FAIL;
 		vmf->pte = pte_offset_map(vmf->pmd, vmf->address);
@@ -4427,8 +4443,11 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
 	old_pte = ptep_modify_prot_start(vma, vmf->address, vmf->pte);
 	pte = pte_modify(old_pte, vma->vm_page_prot);
 	pte = pte_mkyoung(pte);
-	if (was_writable)
+	if (was_writable) {
 		pte = pte_mkwrite(pte);
+		if (vmf->flags & FAULT_FLAG_WRITE)
+			pte = pte_mkdirty(pte);
+	}
 	ptep_modify_prot_commit(vma, vmf->address, vmf->pte, old_pte, pte);
 	update_mmu_cache(vma, vmf->address, vmf->pte);
 	pte_unmap_unlock(vmf->pte, vmf->ptl);
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] mm: add access/dirty bit on numa page fault
  2022-03-17  6:50 [PATCH v2] mm: add access/dirty bit on numa page fault Bibo Mao
@ 2022-03-17 12:23 ` Matthew Wilcox
  2022-03-18  1:01   ` maobibo
  2022-03-17 12:32 ` David Hildenbrand
  1 sibling, 1 reply; 9+ messages in thread
From: Matthew Wilcox @ 2022-03-17 12:23 UTC (permalink / raw)
  To: Bibo Mao; +Cc: Andrew Morton, linux-mm, linux-kernel, Anshuman Khandual

On Thu, Mar 17, 2022 at 02:50:33AM -0400, Bibo Mao wrote:
> On platforms like x86/arm which supports hw page walking, access
> and dirty bit is set by hw, however on some platforms without
> such hw functions, access and dirty bit is set by software in
> next trap.
> 
> During numa page fault, dirty bit can be added for old pte if
> fail to migrate on write fault. And if it succeeds to migrate,
> access bit can be added for migrated new pte, also dirty bit
> can be added for write fault.

Is this a correctness problem, in which case this will need to be
backported, or is this a performance problem, in which case can you
share some numbers?

> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
> ---
>  mm/memory.c | 21 ++++++++++++++++++++-
>  1 file changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/memory.c b/mm/memory.c
> index c125c4969913..65813bec9c06 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4404,6 +4404,22 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
>  	if (migrate_misplaced_page(page, vma, target_nid)) {
>  		page_nid = target_nid;
>  		flags |= TNF_MIGRATED;
> +
> +		/*
> +		 * update pte entry with access bit, and dirty bit for
> +		 * write fault
> +		 */
> +		spin_lock(vmf->ptl);
> +		pte = *vmf->pte;
> +		pte = pte_mkyoung(pte);
> +		if (was_writable) {
> +			pte = pte_mkwrite(pte);
> +			if (vmf->flags & FAULT_FLAG_WRITE)
> +				pte = pte_mkdirty(pte);
> +		}
> +		set_pte_at(vma->vm_mm, vmf->address, vmf->pte, pte);
> +		update_mmu_cache(vma, vmf->address, vmf->pte);
> +		pte_unmap_unlock(vmf->pte, vmf->ptl);
>  	} else {
>  		flags |= TNF_MIGRATE_FAIL;
>  		vmf->pte = pte_offset_map(vmf->pmd, vmf->address);
> @@ -4427,8 +4443,11 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
>  	old_pte = ptep_modify_prot_start(vma, vmf->address, vmf->pte);
>  	pte = pte_modify(old_pte, vma->vm_page_prot);
>  	pte = pte_mkyoung(pte);
> -	if (was_writable)
> +	if (was_writable) {
>  		pte = pte_mkwrite(pte);
> +		if (vmf->flags & FAULT_FLAG_WRITE)
> +			pte = pte_mkdirty(pte);
> +	}
>  	ptep_modify_prot_commit(vma, vmf->address, vmf->pte, old_pte, pte);
>  	update_mmu_cache(vma, vmf->address, vmf->pte);
>  	pte_unmap_unlock(vmf->pte, vmf->ptl);
> -- 
> 2.31.1
> 
> 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] mm: add access/dirty bit on numa page fault
  2022-03-17  6:50 [PATCH v2] mm: add access/dirty bit on numa page fault Bibo Mao
  2022-03-17 12:23 ` Matthew Wilcox
@ 2022-03-17 12:32 ` David Hildenbrand
  2022-03-18  1:17   ` maobibo
  1 sibling, 1 reply; 9+ messages in thread
From: David Hildenbrand @ 2022-03-17 12:32 UTC (permalink / raw)
  To: Bibo Mao, Andrew Morton; +Cc: linux-mm, linux-kernel, Anshuman Khandual

On 17.03.22 07:50, Bibo Mao wrote:
> On platforms like x86/arm which supports hw page walking, access
> and dirty bit is set by hw, however on some platforms without
> such hw functions, access and dirty bit is set by software in
> next trap.
> 
> During numa page fault, dirty bit can be added for old pte if
> fail to migrate on write fault. And if it succeeds to migrate,
> access bit can be added for migrated new pte, also dirty bit
> can be added for write fault.
> 
> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
> ---
>  mm/memory.c | 21 ++++++++++++++++++++-
>  1 file changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/memory.c b/mm/memory.c
> index c125c4969913..65813bec9c06 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4404,6 +4404,22 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
>  	if (migrate_misplaced_page(page, vma, target_nid)) {
>  		page_nid = target_nid;
>  		flags |= TNF_MIGRATED;
> +
> +		/*
> +		 * update pte entry with access bit, and dirty bit for
> +		 * write fault
> +		 */
> +		spin_lock(vmf->ptl);

Ehm, are you sure? We did a pte_unmap_unlock(), so you most certainly need a

vmf->pte = pte_offset_map(vmf->pmd, vmf->address);


Also, don't we need pte_same() checks before we do anything after
dropping the PT lock?

> +		pte = *vmf->pte;
> +		pte = pte_mkyoung(pte);
> +		if (was_writable) {
> +			pte = pte_mkwrite(pte);
> +			if (vmf->flags & FAULT_FLAG_WRITE)
> +				pte = pte_mkdirty(pte);
> +		}
> +		set_pte_at(vma->vm_mm, vmf->address, vmf->pte, pte);
> +		update_mmu_cache(vma, vmf->address, vmf->pte);
> +		pte_unmap_unlock(vmf->pte, vmf->ptl);
>  	} else {
>  		flags |= TNF_MIGRATE_FAIL;
>  		vmf->pte = pte_offset_map(vmf->pmd, vmf->address);
> @@ -4427,8 +4443,11 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
>  	old_pte = ptep_modify_prot_start(vma, vmf->address, vmf->pte);
>  	pte = pte_modify(old_pte, vma->vm_page_prot);
>  	pte = pte_mkyoung(pte);
> -	if (was_writable)
> +	if (was_writable) {
>  		pte = pte_mkwrite(pte);
> +		if (vmf->flags & FAULT_FLAG_WRITE)
> +			pte = pte_mkdirty(pte);
> +	}
>  	ptep_modify_prot_commit(vma, vmf->address, vmf->pte, old_pte, pte);
>  	update_mmu_cache(vma, vmf->address, vmf->pte);
>  	pte_unmap_unlock(vmf->pte, vmf->ptl);


-- 
Thanks,

David / dhildenb


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] mm: add access/dirty bit on numa page fault
  2022-03-17 12:23 ` Matthew Wilcox
@ 2022-03-18  1:01   ` maobibo
  2022-03-18  1:46     ` Matthew Wilcox
  0 siblings, 1 reply; 9+ messages in thread
From: maobibo @ 2022-03-18  1:01 UTC (permalink / raw)
  To: Matthew Wilcox; +Cc: Andrew Morton, linux-mm, linux-kernel, Anshuman Khandual



On 03/17/2022 08:23 PM, Matthew Wilcox wrote:
> On Thu, Mar 17, 2022 at 02:50:33AM -0400, Bibo Mao wrote:
>> On platforms like x86/arm which supports hw page walking, access
>> and dirty bit is set by hw, however on some platforms without
>> such hw functions, access and dirty bit is set by software in
>> next trap.
>>
>> During numa page fault, dirty bit can be added for old pte if
>> fail to migrate on write fault. And if it succeeds to migrate,
>> access bit can be added for migrated new pte, also dirty bit
>> can be added for write fault.
> 
> Is this a correctness problem, in which case this will need to be
> backported, or is this a performance problem, in which case can you
> share some numbers?
It is only performance issue, and there is no obvious performance
improvement for general workloads on my hand, but I do not test
it on microbenchmark.

> 
>> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
>> ---
>>  mm/memory.c | 21 ++++++++++++++++++++-
>>  1 file changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/memory.c b/mm/memory.c
>> index c125c4969913..65813bec9c06 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -4404,6 +4404,22 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
>>  	if (migrate_misplaced_page(page, vma, target_nid)) {
>>  		page_nid = target_nid;
>>  		flags |= TNF_MIGRATED;
>> +
>> +		/*
>> +		 * update pte entry with access bit, and dirty bit for
>> +		 * write fault
>> +		 */
>> +		spin_lock(vmf->ptl);
>> +		pte = *vmf->pte;
>> +		pte = pte_mkyoung(pte);
>> +		if (was_writable) {
>> +			pte = pte_mkwrite(pte);
>> +			if (vmf->flags & FAULT_FLAG_WRITE)
>> +				pte = pte_mkdirty(pte);
>> +		}
>> +		set_pte_at(vma->vm_mm, vmf->address, vmf->pte, pte);
>> +		update_mmu_cache(vma, vmf->address, vmf->pte);
>> +		pte_unmap_unlock(vmf->pte, vmf->ptl);
>>  	} else {
>>  		flags |= TNF_MIGRATE_FAIL;
>>  		vmf->pte = pte_offset_map(vmf->pmd, vmf->address);
>> @@ -4427,8 +4443,11 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
>>  	old_pte = ptep_modify_prot_start(vma, vmf->address, vmf->pte);
>>  	pte = pte_modify(old_pte, vma->vm_page_prot);
>>  	pte = pte_mkyoung(pte);
>> -	if (was_writable)
>> +	if (was_writable) {
>>  		pte = pte_mkwrite(pte);
>> +		if (vmf->flags & FAULT_FLAG_WRITE)
>> +			pte = pte_mkdirty(pte);
>> +	}
>>  	ptep_modify_prot_commit(vma, vmf->address, vmf->pte, old_pte, pte);
>>  	update_mmu_cache(vma, vmf->address, vmf->pte);
>>  	pte_unmap_unlock(vmf->pte, vmf->ptl);
>> -- 
>> 2.31.1
>>
>>


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] mm: add access/dirty bit on numa page fault
  2022-03-17 12:32 ` David Hildenbrand
@ 2022-03-18  1:17   ` maobibo
  2022-03-18  8:21     ` David Hildenbrand
  0 siblings, 1 reply; 9+ messages in thread
From: maobibo @ 2022-03-18  1:17 UTC (permalink / raw)
  To: David Hildenbrand, Andrew Morton
  Cc: linux-mm, linux-kernel, Anshuman Khandual



On 03/17/2022 08:32 PM, David Hildenbrand wrote:
> On 17.03.22 07:50, Bibo Mao wrote:
>> On platforms like x86/arm which supports hw page walking, access
>> and dirty bit is set by hw, however on some platforms without
>> such hw functions, access and dirty bit is set by software in
>> next trap.
>>
>> During numa page fault, dirty bit can be added for old pte if
>> fail to migrate on write fault. And if it succeeds to migrate,
>> access bit can be added for migrated new pte, also dirty bit
>> can be added for write fault.
>>
>> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
>> ---
>>  mm/memory.c | 21 ++++++++++++++++++++-
>>  1 file changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/memory.c b/mm/memory.c
>> index c125c4969913..65813bec9c06 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -4404,6 +4404,22 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
>>  	if (migrate_misplaced_page(page, vma, target_nid)) {
>>  		page_nid = target_nid;
>>  		flags |= TNF_MIGRATED;
>> +
>> +		/*
>> +		 * update pte entry with access bit, and dirty bit for
>> +		 * write fault
>> +		 */
>> +		spin_lock(vmf->ptl);
> 
> Ehm, are you sure? We did a pte_unmap_unlock(), so you most certainly need a
> 
> vmf->pte = pte_offset_map(vmf->pmd, vmf->address);
yes, we need probe pte entry again after function pte_unmap_unlock().
> 
> 
> Also, don't we need pte_same() checks before we do anything after
> dropping the PT lock?
I do not think so. If page succeeds in migration, pte entry should be changed
also, it should be different.

regards
bibo,mao

> 
>> +		pte = *vmf->pte;
>> +		pte = pte_mkyoung(pte);
>> +		if (was_writable) {
>> +			pte = pte_mkwrite(pte);
>> +			if (vmf->flags & FAULT_FLAG_WRITE)
>> +				pte = pte_mkdirty(pte);
>> +		}
>> +		set_pte_at(vma->vm_mm, vmf->address, vmf->pte, pte);
>> +		update_mmu_cache(vma, vmf->address, vmf->pte);
>> +		pte_unmap_unlock(vmf->pte, vmf->ptl);
>>  	} else {
>>  		flags |= TNF_MIGRATE_FAIL;
>>  		vmf->pte = pte_offset_map(vmf->pmd, vmf->address);
>> @@ -4427,8 +4443,11 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
>>  	old_pte = ptep_modify_prot_start(vma, vmf->address, vmf->pte);
>>  	pte = pte_modify(old_pte, vma->vm_page_prot);
>>  	pte = pte_mkyoung(pte);
>> -	if (was_writable)
>> +	if (was_writable) {
>>  		pte = pte_mkwrite(pte);
>> +		if (vmf->flags & FAULT_FLAG_WRITE)
>> +			pte = pte_mkdirty(pte);
>> +	}
>>  	ptep_modify_prot_commit(vma, vmf->address, vmf->pte, old_pte, pte);
>>  	update_mmu_cache(vma, vmf->address, vmf->pte);
>>  	pte_unmap_unlock(vmf->pte, vmf->ptl);
> 
> 


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] mm: add access/dirty bit on numa page fault
  2022-03-18  1:01   ` maobibo
@ 2022-03-18  1:46     ` Matthew Wilcox
  2022-03-18  2:17       ` maobibo
  0 siblings, 1 reply; 9+ messages in thread
From: Matthew Wilcox @ 2022-03-18  1:46 UTC (permalink / raw)
  To: maobibo; +Cc: Andrew Morton, linux-mm, linux-kernel, Anshuman Khandual

On Fri, Mar 18, 2022 at 09:01:32AM +0800, maobibo wrote:
> > Is this a correctness problem, in which case this will need to be
> > backported, or is this a performance problem, in which case can you
> > share some numbers?
> It is only performance issue, and there is no obvious performance
> improvement for general workloads on my hand, but I do not test
> it on microbenchmark.

... if there's no performance improvement, why should we apply this
patch?  Confused.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] mm: add access/dirty bit on numa page fault
  2022-03-18  1:46     ` Matthew Wilcox
@ 2022-03-18  2:17       ` maobibo
  0 siblings, 0 replies; 9+ messages in thread
From: maobibo @ 2022-03-18  2:17 UTC (permalink / raw)
  To: Matthew Wilcox; +Cc: Andrew Morton, linux-mm, linux-kernel, Anshuman Khandual



On 03/18/2022 09:46 AM, Matthew Wilcox wrote:
> On Fri, Mar 18, 2022 at 09:01:32AM +0800, maobibo wrote:
>>> Is this a correctness problem, in which case this will need to be
>>> backported, or is this a performance problem, in which case can you
>>> share some numbers?
>> It is only performance issue, and there is no obvious performance
>> improvement for general workloads on my hand, but I do not test
>> it on microbenchmark.
> 
> ... if there's no performance improvement, why should we apply this
> patch?  Confused.
> 
It is not obvious from workload view, it actually reduces one tlb miss
on platforms without hw page walk.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] mm: add access/dirty bit on numa page fault
  2022-03-18  1:17   ` maobibo
@ 2022-03-18  8:21     ` David Hildenbrand
  2022-03-19  2:58       ` maobibo
  0 siblings, 1 reply; 9+ messages in thread
From: David Hildenbrand @ 2022-03-18  8:21 UTC (permalink / raw)
  To: maobibo, Andrew Morton; +Cc: linux-mm, linux-kernel, Anshuman Khandual

On 18.03.22 02:17, maobibo wrote:
> 
> 
> On 03/17/2022 08:32 PM, David Hildenbrand wrote:
>> On 17.03.22 07:50, Bibo Mao wrote:
>>> On platforms like x86/arm which supports hw page walking, access
>>> and dirty bit is set by hw, however on some platforms without
>>> such hw functions, access and dirty bit is set by software in
>>> next trap.
>>>
>>> During numa page fault, dirty bit can be added for old pte if
>>> fail to migrate on write fault. And if it succeeds to migrate,
>>> access bit can be added for migrated new pte, also dirty bit
>>> can be added for write fault.
>>>
>>> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
>>> ---
>>>  mm/memory.c | 21 ++++++++++++++++++++-
>>>  1 file changed, 20 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/mm/memory.c b/mm/memory.c
>>> index c125c4969913..65813bec9c06 100644
>>> --- a/mm/memory.c
>>> +++ b/mm/memory.c
>>> @@ -4404,6 +4404,22 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
>>>  	if (migrate_misplaced_page(page, vma, target_nid)) {
>>>  		page_nid = target_nid;
>>>  		flags |= TNF_MIGRATED;
>>> +
>>> +		/*
>>> +		 * update pte entry with access bit, and dirty bit for
>>> +		 * write fault
>>> +		 */
>>> +		spin_lock(vmf->ptl);
>>
>> Ehm, are you sure? We did a pte_unmap_unlock(), so you most certainly need a
>>
>> vmf->pte = pte_offset_map(vmf->pmd, vmf->address);
> yes, we need probe pte entry again after function pte_unmap_unlock().
>>
>>
>> Also, don't we need pte_same() checks before we do anything after
>> dropping the PT lock?
> I do not think so. If page succeeds in migration, pte entry should be changed
> also, it should be different.
> 

We have to be very careful here. Page migration succeeded, so I do
wonder if you have to do anything on this branch *at all*. I'd assume
that page migration too care of that already.

See, when only holding the mmap lock in read mode, there are absolutely
no guarantees what will happen after dropping the PT lock. The page
could get unmapped and another page could get mapped. The page could
have been mapped R/O in the meantime.

So I'm pretty sure that unconditionally modifying the PTE here is wrong.

-- 
Thanks,

David / dhildenb


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] mm: add access/dirty bit on numa page fault
  2022-03-18  8:21     ` David Hildenbrand
@ 2022-03-19  2:58       ` maobibo
  0 siblings, 0 replies; 9+ messages in thread
From: maobibo @ 2022-03-19  2:58 UTC (permalink / raw)
  To: David Hildenbrand, Andrew Morton
  Cc: linux-mm, linux-kernel, Anshuman Khandual



On 03/18/2022 04:21 PM, David Hildenbrand wrote:
> On 18.03.22 02:17, maobibo wrote:
>>
>>
>> On 03/17/2022 08:32 PM, David Hildenbrand wrote:
>>> On 17.03.22 07:50, Bibo Mao wrote:
>>>> On platforms like x86/arm which supports hw page walking, access
>>>> and dirty bit is set by hw, however on some platforms without
>>>> such hw functions, access and dirty bit is set by software in
>>>> next trap.
>>>>
>>>> During numa page fault, dirty bit can be added for old pte if
>>>> fail to migrate on write fault. And if it succeeds to migrate,
>>>> access bit can be added for migrated new pte, also dirty bit
>>>> can be added for write fault.
>>>>
>>>> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
>>>> ---
>>>>  mm/memory.c | 21 ++++++++++++++++++++-
>>>>  1 file changed, 20 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/mm/memory.c b/mm/memory.c
>>>> index c125c4969913..65813bec9c06 100644
>>>> --- a/mm/memory.c
>>>> +++ b/mm/memory.c
>>>> @@ -4404,6 +4404,22 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
>>>>  	if (migrate_misplaced_page(page, vma, target_nid)) {
>>>>  		page_nid = target_nid;
>>>>  		flags |= TNF_MIGRATED;
>>>> +
>>>> +		/*
>>>> +		 * update pte entry with access bit, and dirty bit for
>>>> +		 * write fault
>>>> +		 */
>>>> +		spin_lock(vmf->ptl);
>>>
>>> Ehm, are you sure? We did a pte_unmap_unlock(), so you most certainly need a
>>>
>>> vmf->pte = pte_offset_map(vmf->pmd, vmf->address);
>> yes, we need probe pte entry again after function pte_unmap_unlock().
>>>
>>>
>>> Also, don't we need pte_same() checks before we do anything after
>>> dropping the PT lock?
>> I do not think so. If page succeeds in migration, pte entry should be changed
>> also, it should be different.
>>
> 
> We have to be very careful here. Page migration succeeded, so I do
> wonder if you have to do anything on this branch *at all*. I'd assume
> that page migration too care of that already.
> 
> See, when only holding the mmap lock in read mode, there are absolutely
> no guarantees what will happen after dropping the PT lock. The page
> could get unmapped and another page could get mapped. The page could
> have been mapped R/O in the meantime.
> 
> So I'm pretty sure that unconditionally modifying the PTE here is wrong.
yes, there will be problem change pte directly, thanks for your guidance:)
it should be done on page migration flow, i will check code of page migration.


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2022-03-19  2:58 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-17  6:50 [PATCH v2] mm: add access/dirty bit on numa page fault Bibo Mao
2022-03-17 12:23 ` Matthew Wilcox
2022-03-18  1:01   ` maobibo
2022-03-18  1:46     ` Matthew Wilcox
2022-03-18  2:17       ` maobibo
2022-03-17 12:32 ` David Hildenbrand
2022-03-18  1:17   ` maobibo
2022-03-18  8:21     ` David Hildenbrand
2022-03-19  2:58       ` maobibo

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.