* [PATCH] mm: dont call mmu_notifier_invalidate_page during munlock
@ 2014-05-28 7:59 ` Konstantin Khlebnikov
0 siblings, 0 replies; 8+ messages in thread
From: Konstantin Khlebnikov @ 2014-05-28 7:59 UTC (permalink / raw)
To: linux-mm, Andrew Morton; +Cc: linux-kernel
try_to_munlock() searches other mlocked vmas, it never unmaps pages.
There is no reason for invalidation because ptes are left unchanged.
Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
---
mm/rmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/rmap.c b/mm/rmap.c
index 9c3e773..75d9d5c 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1225,7 +1225,7 @@ int try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
out_unmap:
pte_unmap_unlock(pte, ptl);
- if (ret != SWAP_FAIL)
+ if (ret != SWAP_FAIL && TTU_ACTION(flags) != TTU_MUNLOCK)
mmu_notifier_invalidate_page(mm, address);
out:
return ret;
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH] mm: dont call mmu_notifier_invalidate_page during munlock
@ 2014-05-28 7:59 ` Konstantin Khlebnikov
0 siblings, 0 replies; 8+ messages in thread
From: Konstantin Khlebnikov @ 2014-05-28 7:59 UTC (permalink / raw)
To: linux-mm, Andrew Morton; +Cc: linux-kernel
try_to_munlock() searches other mlocked vmas, it never unmaps pages.
There is no reason for invalidation because ptes are left unchanged.
Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
---
mm/rmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/rmap.c b/mm/rmap.c
index 9c3e773..75d9d5c 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1225,7 +1225,7 @@ int try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
out_unmap:
pte_unmap_unlock(pte, ptl);
- if (ret != SWAP_FAIL)
+ if (ret != SWAP_FAIL && TTU_ACTION(flags) != TTU_MUNLOCK)
mmu_notifier_invalidate_page(mm, address);
out:
return ret;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] mm: dont call mmu_notifier_invalidate_page during munlock
2014-05-28 7:59 ` Konstantin Khlebnikov
@ 2014-05-28 23:09 ` Andrew Morton
-1 siblings, 0 replies; 8+ messages in thread
From: Andrew Morton @ 2014-05-28 23:09 UTC (permalink / raw)
To: Konstantin Khlebnikov; +Cc: linux-mm, linux-kernel
On Wed, 28 May 2014 11:59:55 +0400 Konstantin Khlebnikov <koct9i@gmail.com> wrote:
> try_to_munlock() searches other mlocked vmas, it never unmaps pages.
> There is no reason for invalidation because ptes are left unchanged.
>
> ...
>
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1225,7 +1225,7 @@ int try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
>
> out_unmap:
> pte_unmap_unlock(pte, ptl);
> - if (ret != SWAP_FAIL)
> + if (ret != SWAP_FAIL && TTU_ACTION(flags) != TTU_MUNLOCK)
> mmu_notifier_invalidate_page(mm, address);
> out:
> return ret;
The patch itself looks reasonable but there is no such thing as
try_to_munlock(). I rewrote the changelog thusly:
: In its munmap mode, try_to_unmap_one() searches other mlocked vmas, it
: never unmaps pages. There is no reason for invalidation because ptes are
: left unchanged.
Also, the name try_to_unmap_one() is now pretty inaccurate/incomplete.
Perhaps if someone is feeling enthusiastic they might think up a better
name for the various try_to_unmap functions and see if we can
appropriately document try_to_unmap_one().
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mm: dont call mmu_notifier_invalidate_page during munlock
@ 2014-05-28 23:09 ` Andrew Morton
0 siblings, 0 replies; 8+ messages in thread
From: Andrew Morton @ 2014-05-28 23:09 UTC (permalink / raw)
To: Konstantin Khlebnikov; +Cc: linux-mm, linux-kernel
On Wed, 28 May 2014 11:59:55 +0400 Konstantin Khlebnikov <koct9i@gmail.com> wrote:
> try_to_munlock() searches other mlocked vmas, it never unmaps pages.
> There is no reason for invalidation because ptes are left unchanged.
>
> ...
>
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1225,7 +1225,7 @@ int try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
>
> out_unmap:
> pte_unmap_unlock(pte, ptl);
> - if (ret != SWAP_FAIL)
> + if (ret != SWAP_FAIL && TTU_ACTION(flags) != TTU_MUNLOCK)
> mmu_notifier_invalidate_page(mm, address);
> out:
> return ret;
The patch itself looks reasonable but there is no such thing as
try_to_munlock(). I rewrote the changelog thusly:
: In its munmap mode, try_to_unmap_one() searches other mlocked vmas, it
: never unmaps pages. There is no reason for invalidation because ptes are
: left unchanged.
Also, the name try_to_unmap_one() is now pretty inaccurate/incomplete.
Perhaps if someone is feeling enthusiastic they might think up a better
name for the various try_to_unmap functions and see if we can
appropriately document try_to_unmap_one().
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mm: dont call mmu_notifier_invalidate_page during munlock
2014-05-28 23:09 ` Andrew Morton
@ 2014-05-29 7:19 ` Konstantin Khlebnikov
-1 siblings, 0 replies; 8+ messages in thread
From: Konstantin Khlebnikov @ 2014-05-29 7:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, Linux Kernel Mailing List
On Thu, May 29, 2014 at 3:09 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Wed, 28 May 2014 11:59:55 +0400 Konstantin Khlebnikov <koct9i@gmail.com> wrote:
>
>> try_to_munlock() searches other mlocked vmas, it never unmaps pages.
>> There is no reason for invalidation because ptes are left unchanged.
>>
>> ...
>>
>> --- a/mm/rmap.c
>> +++ b/mm/rmap.c
>> @@ -1225,7 +1225,7 @@ int try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
>>
>> out_unmap:
>> pte_unmap_unlock(pte, ptl);
>> - if (ret != SWAP_FAIL)
>> + if (ret != SWAP_FAIL && TTU_ACTION(flags) != TTU_MUNLOCK)
>> mmu_notifier_invalidate_page(mm, address);
>> out:
>> return ret;
>
> The patch itself looks reasonable but there is no such thing as
> try_to_munlock(). I rewrote the changelog thusly:
Wait, what? I do have function with this name in my sources. It calls rmap_walk
with callback try_to_unmap_one and action TTU_MUNLOCK. This is the place
where TTU_MUNLOCK is used, I've mentioned it as entry point of this logic.
>
> : In its munmap mode, try_to_unmap_one() searches other mlocked vmas, it
> : never unmaps pages. There is no reason for invalidation because ptes are
> : left unchanged.
>
> Also, the name try_to_unmap_one() is now pretty inaccurate/incomplete.
> Perhaps if someone is feeling enthusiastic they might think up a better
> name for the various try_to_unmap functions and see if we can
> appropriately document try_to_unmap_one().
I thought about moving mlock part out of try_to_unmap_one() into
separate function,
but normal unmap needs this part too...
Anyway I want to make try_to_unmap_one() static, this is internal function now.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mm: dont call mmu_notifier_invalidate_page during munlock
@ 2014-05-29 7:19 ` Konstantin Khlebnikov
0 siblings, 0 replies; 8+ messages in thread
From: Konstantin Khlebnikov @ 2014-05-29 7:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, Linux Kernel Mailing List
On Thu, May 29, 2014 at 3:09 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Wed, 28 May 2014 11:59:55 +0400 Konstantin Khlebnikov <koct9i@gmail.com> wrote:
>
>> try_to_munlock() searches other mlocked vmas, it never unmaps pages.
>> There is no reason for invalidation because ptes are left unchanged.
>>
>> ...
>>
>> --- a/mm/rmap.c
>> +++ b/mm/rmap.c
>> @@ -1225,7 +1225,7 @@ int try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
>>
>> out_unmap:
>> pte_unmap_unlock(pte, ptl);
>> - if (ret != SWAP_FAIL)
>> + if (ret != SWAP_FAIL && TTU_ACTION(flags) != TTU_MUNLOCK)
>> mmu_notifier_invalidate_page(mm, address);
>> out:
>> return ret;
>
> The patch itself looks reasonable but there is no such thing as
> try_to_munlock(). I rewrote the changelog thusly:
Wait, what? I do have function with this name in my sources. It calls rmap_walk
with callback try_to_unmap_one and action TTU_MUNLOCK. This is the place
where TTU_MUNLOCK is used, I've mentioned it as entry point of this logic.
>
> : In its munmap mode, try_to_unmap_one() searches other mlocked vmas, it
> : never unmaps pages. There is no reason for invalidation because ptes are
> : left unchanged.
>
> Also, the name try_to_unmap_one() is now pretty inaccurate/incomplete.
> Perhaps if someone is feeling enthusiastic they might think up a better
> name for the various try_to_unmap functions and see if we can
> appropriately document try_to_unmap_one().
I thought about moving mlock part out of try_to_unmap_one() into
separate function,
but normal unmap needs this part too...
Anyway I want to make try_to_unmap_one() static, this is internal function now.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mm: dont call mmu_notifier_invalidate_page during munlock
2014-05-29 7:19 ` Konstantin Khlebnikov
@ 2014-05-29 9:04 ` Andrew Morton
-1 siblings, 0 replies; 8+ messages in thread
From: Andrew Morton @ 2014-05-29 9:04 UTC (permalink / raw)
To: Konstantin Khlebnikov; +Cc: linux-mm, Linux Kernel Mailing List
On Thu, 29 May 2014 11:19:27 +0400 Konstantin Khlebnikov <koct9i@gmail.com> wrote:
> On Thu, May 29, 2014 at 3:09 AM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Wed, 28 May 2014 11:59:55 +0400 Konstantin Khlebnikov <koct9i@gmail.com> wrote:
> >
> >> try_to_munlock() searches other mlocked vmas, it never unmaps pages.
> >> There is no reason for invalidation because ptes are left unchanged.
> >>
> >> ...
> >>
> >> --- a/mm/rmap.c
> >> +++ b/mm/rmap.c
> >> @@ -1225,7 +1225,7 @@ int try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
> >>
> >> out_unmap:
> >> pte_unmap_unlock(pte, ptl);
> >> - if (ret != SWAP_FAIL)
> >> + if (ret != SWAP_FAIL && TTU_ACTION(flags) != TTU_MUNLOCK)
> >> mmu_notifier_invalidate_page(mm, address);
> >> out:
> >> return ret;
> >
> > The patch itself looks reasonable but there is no such thing as
> > try_to_munlock(). I rewrote the changelog thusly:
>
> Wait, what? I do have function with this name in my sources. It calls rmap_walk
> with callback try_to_unmap_one and action TTU_MUNLOCK. This is the place
> where TTU_MUNLOCK is used, I've mentioned it as entry point of this logic.
Ah OK, I obviously misgrepped.
> >
> > : In its munmap mode, try_to_unmap_one() searches other mlocked vmas, it
> > : never unmaps pages. There is no reason for invalidation because ptes are
> > : left unchanged.
> >
> > Also, the name try_to_unmap_one() is now pretty inaccurate/incomplete.
> > Perhaps if someone is feeling enthusiastic they might think up a better
> > name for the various try_to_unmap functions and see if we can
> > appropriately document try_to_unmap_one().
>
> I thought about moving mlock part out of try_to_unmap_one() into
> separate function,
> but normal unmap needs this part too...
try_to_unmap_one() does appear to have enough in common with the
munlock operation to justify using common code. But doing so makes the
name wrong.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mm: dont call mmu_notifier_invalidate_page during munlock
@ 2014-05-29 9:04 ` Andrew Morton
0 siblings, 0 replies; 8+ messages in thread
From: Andrew Morton @ 2014-05-29 9:04 UTC (permalink / raw)
To: Konstantin Khlebnikov; +Cc: linux-mm, Linux Kernel Mailing List
On Thu, 29 May 2014 11:19:27 +0400 Konstantin Khlebnikov <koct9i@gmail.com> wrote:
> On Thu, May 29, 2014 at 3:09 AM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Wed, 28 May 2014 11:59:55 +0400 Konstantin Khlebnikov <koct9i@gmail.com> wrote:
> >
> >> try_to_munlock() searches other mlocked vmas, it never unmaps pages.
> >> There is no reason for invalidation because ptes are left unchanged.
> >>
> >> ...
> >>
> >> --- a/mm/rmap.c
> >> +++ b/mm/rmap.c
> >> @@ -1225,7 +1225,7 @@ int try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
> >>
> >> out_unmap:
> >> pte_unmap_unlock(pte, ptl);
> >> - if (ret != SWAP_FAIL)
> >> + if (ret != SWAP_FAIL && TTU_ACTION(flags) != TTU_MUNLOCK)
> >> mmu_notifier_invalidate_page(mm, address);
> >> out:
> >> return ret;
> >
> > The patch itself looks reasonable but there is no such thing as
> > try_to_munlock(). I rewrote the changelog thusly:
>
> Wait, what? I do have function with this name in my sources. It calls rmap_walk
> with callback try_to_unmap_one and action TTU_MUNLOCK. This is the place
> where TTU_MUNLOCK is used, I've mentioned it as entry point of this logic.
Ah OK, I obviously misgrepped.
> >
> > : In its munmap mode, try_to_unmap_one() searches other mlocked vmas, it
> > : never unmaps pages. There is no reason for invalidation because ptes are
> > : left unchanged.
> >
> > Also, the name try_to_unmap_one() is now pretty inaccurate/incomplete.
> > Perhaps if someone is feeling enthusiastic they might think up a better
> > name for the various try_to_unmap functions and see if we can
> > appropriately document try_to_unmap_one().
>
> I thought about moving mlock part out of try_to_unmap_one() into
> separate function,
> but normal unmap needs this part too...
try_to_unmap_one() does appear to have enough in common with the
munlock operation to justify using common code. But doing so makes the
name wrong.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-05-29 9:06 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-28 7:59 [PATCH] mm: dont call mmu_notifier_invalidate_page during munlock Konstantin Khlebnikov
2014-05-28 7:59 ` Konstantin Khlebnikov
2014-05-28 23:09 ` Andrew Morton
2014-05-28 23:09 ` Andrew Morton
2014-05-29 7:19 ` Konstantin Khlebnikov
2014-05-29 7:19 ` Konstantin Khlebnikov
2014-05-29 9:04 ` Andrew Morton
2014-05-29 9:04 ` Andrew Morton
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.