Linux-mm Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH 1/3] mm/mmap.c: prev could be retrieved from vma->vm_prev
@ 2019-08-14  2:17 Wei Yang
  2019-08-14  2:17 ` [PATCH 2/3] mm/mmap.c: __vma_unlink_prev is not necessary now Wei Yang
  2019-08-14  2:17 ` [PATCH 3/3] mm/mmap.c: extract __vma_unlink_list as counter part for __vma_link_list Wei Yang
  0 siblings, 2 replies; 13+ messages in thread
From: Wei Yang @ 2019-08-14  2:17 UTC (permalink / raw)
  To: akpm, mgorman, vbabka, osalvador; +Cc: linux-mm, linux-kernel, Wei Yang

Currently __vma_unlink_common handles two cases:

  * has_prev
  * or not

When has_prev is false, it is obvious prev is calculated from
vma->vm_prev in __vma_unlink_common.

When has_prev is true, the prev is passed through from __vma_unlink_prev
in __vma_adjust for non-case 8. And at the beginning next is calculated
from vma->vm_next, which implies vma is next->vm_prev.

The above statement sounds a little complicated, while to think in
another point of view, no matter whether vma and next is swapped, the
mmap link list still preserves its property. It is proper to access
vma->vm_prev.

Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
---
 mm/mmap.c | 20 +++++++-------------
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index b8072630766f..3d56340fea36 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -675,23 +675,17 @@ static void __insert_vm_struct(struct mm_struct *mm, struct vm_area_struct *vma)
 
 static __always_inline void __vma_unlink_common(struct mm_struct *mm,
 						struct vm_area_struct *vma,
-						struct vm_area_struct *prev,
-						bool has_prev,
 						struct vm_area_struct *ignore)
 {
-	struct vm_area_struct *next;
+	struct vm_area_struct *prev, *next;
 
 	vma_rb_erase_ignore(vma, &mm->mm_rb, ignore);
 	next = vma->vm_next;
-	if (has_prev)
+	prev = vma->vm_prev;
+	if (prev)
 		prev->vm_next = next;
-	else {
-		prev = vma->vm_prev;
-		if (prev)
-			prev->vm_next = next;
-		else
-			mm->mmap = next;
-	}
+	else
+		mm->mmap = next;
 	if (next)
 		next->vm_prev = prev;
 
@@ -703,7 +697,7 @@ static inline void __vma_unlink_prev(struct mm_struct *mm,
 				     struct vm_area_struct *vma,
 				     struct vm_area_struct *prev)
 {
-	__vma_unlink_common(mm, vma, prev, true, vma);
+	__vma_unlink_common(mm, vma, vma);
 }
 
 /*
@@ -891,7 +885,7 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long start,
 			 * "next" (which is stored in post-swap()
 			 * "vma").
 			 */
-			__vma_unlink_common(mm, next, NULL, false, vma);
+			__vma_unlink_common(mm, next, vma);
 		if (file)
 			__remove_shared_vm_struct(next, file, mapping);
 	} else if (insert) {
-- 
2.17.1



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

* [PATCH 2/3] mm/mmap.c: __vma_unlink_prev is not necessary now
  2019-08-14  2:17 [PATCH 1/3] mm/mmap.c: prev could be retrieved from vma->vm_prev Wei Yang
@ 2019-08-14  2:17 ` Wei Yang
  2019-08-14  2:17 ` [PATCH 3/3] mm/mmap.c: extract __vma_unlink_list as counter part for __vma_link_list Wei Yang
  1 sibling, 0 replies; 13+ messages in thread
From: Wei Yang @ 2019-08-14  2:17 UTC (permalink / raw)
  To: akpm, mgorman, vbabka, osalvador; +Cc: linux-mm, linux-kernel, Wei Yang

The third parameter of __vma_unlink_common could differentiate these two
types. __vma_unlink_prev is not necessary now.

Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
---
 mm/mmap.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index 3d56340fea36..3fde0ec18554 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -693,13 +693,6 @@ static __always_inline void __vma_unlink_common(struct mm_struct *mm,
 	vmacache_invalidate(mm);
 }
 
-static inline void __vma_unlink_prev(struct mm_struct *mm,
-				     struct vm_area_struct *vma,
-				     struct vm_area_struct *prev)
-{
-	__vma_unlink_common(mm, vma, vma);
-}
-
 /*
  * We cannot adjust vm_start, vm_end, vm_pgoff fields of a vma that
  * is already present in an i_mmap tree without adjusting the tree.
@@ -874,7 +867,7 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long start,
 		 * us to remove next before dropping the locks.
 		 */
 		if (remove_next != 3)
-			__vma_unlink_prev(mm, next, vma);
+			__vma_unlink_common(mm, next, next);
 		else
 			/*
 			 * vma is not before next if they've been
-- 
2.17.1



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

* [PATCH 3/3] mm/mmap.c: extract __vma_unlink_list as counter part for __vma_link_list
  2019-08-14  2:17 [PATCH 1/3] mm/mmap.c: prev could be retrieved from vma->vm_prev Wei Yang
  2019-08-14  2:17 ` [PATCH 2/3] mm/mmap.c: __vma_unlink_prev is not necessary now Wei Yang
@ 2019-08-14  2:17 ` Wei Yang
  2019-08-14  5:16   ` Christoph Hellwig
  1 sibling, 1 reply; 13+ messages in thread
From: Wei Yang @ 2019-08-14  2:17 UTC (permalink / raw)
  To: akpm, mgorman, vbabka, osalvador; +Cc: linux-mm, linux-kernel, Wei Yang

Just make the code a little easy to read.

Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>

---
Note: For nommu part, the code is not tested.
---
 mm/internal.h |  1 +
 mm/mmap.c     | 12 +-----------
 mm/nommu.c    |  8 +-------
 mm/util.c     | 14 ++++++++++++++
 4 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/mm/internal.h b/mm/internal.h
index 41a49574acc3..4736aeb37dae 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -291,6 +291,7 @@ static inline bool is_data_mapping(vm_flags_t flags)
 /* mm/util.c */
 void __vma_link_list(struct mm_struct *mm, struct vm_area_struct *vma,
 		struct vm_area_struct *prev);
+void __vma_unlink_list(struct mm_struct *mm, struct vm_area_struct *vma);
 
 #ifdef CONFIG_MMU
 extern long populate_vma_page_range(struct vm_area_struct *vma,
diff --git a/mm/mmap.c b/mm/mmap.c
index 3fde0ec18554..aa66753b175e 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -677,18 +677,8 @@ static __always_inline void __vma_unlink_common(struct mm_struct *mm,
 						struct vm_area_struct *vma,
 						struct vm_area_struct *ignore)
 {
-	struct vm_area_struct *prev, *next;
-
 	vma_rb_erase_ignore(vma, &mm->mm_rb, ignore);
-	next = vma->vm_next;
-	prev = vma->vm_prev;
-	if (prev)
-		prev->vm_next = next;
-	else
-		mm->mmap = next;
-	if (next)
-		next->vm_prev = prev;
-
+	__vma_unlink_list(mm, vma);
 	/* Kill the cache */
 	vmacache_invalidate(mm);
 }
diff --git a/mm/nommu.c b/mm/nommu.c
index 12a66fbeb988..1a403f65b99e 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -673,13 +673,7 @@ static void delete_vma_from_mm(struct vm_area_struct *vma)
 	/* remove from the MM's tree and list */
 	rb_erase(&vma->vm_rb, &mm->mm_rb);
 
-	if (vma->vm_prev)
-		vma->vm_prev->vm_next = vma->vm_next;
-	else
-		mm->mmap = vma->vm_next;
-
-	if (vma->vm_next)
-		vma->vm_next->vm_prev = vma->vm_prev;
+	__vma_unlink_list(mm, vma);
 }
 
 /*
diff --git a/mm/util.c b/mm/util.c
index 80632db29247..5f113cd0acad 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -281,6 +281,20 @@ void __vma_link_list(struct mm_struct *mm, struct vm_area_struct *vma,
 		next->vm_prev = vma;
 }
 
+void __vma_unlink_list(struct mm_struct *mm, struct vm_area_struct *vma)
+{
+	struct vm_area_struct *prev, *next;
+
+	next = vma->vm_next;
+	prev = vma->vm_prev;
+	if (prev)
+		prev->vm_next = next;
+	else
+		mm->mmap = next;
+	if (next)
+		next->vm_prev = prev;
+}
+
 /* Check if the vma is being used as a stack by this task */
 int vma_is_stack_for_current(struct vm_area_struct *vma)
 {
-- 
2.17.1



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

* Re: [PATCH 3/3] mm/mmap.c: extract __vma_unlink_list as counter part for __vma_link_list
  2019-08-14  2:17 ` [PATCH 3/3] mm/mmap.c: extract __vma_unlink_list as counter part for __vma_link_list Wei Yang
@ 2019-08-14  5:16   ` Christoph Hellwig
  2019-08-14  6:57     ` Wei Yang
  0 siblings, 1 reply; 13+ messages in thread
From: Christoph Hellwig @ 2019-08-14  5:16 UTC (permalink / raw)
  To: Wei Yang; +Cc: akpm, mgorman, vbabka, osalvador, linux-mm, linux-kernel

Btw, is there any good reason we don't use a list_head for vma linkage?


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

* Re: [PATCH 3/3] mm/mmap.c: extract __vma_unlink_list as counter part for __vma_link_list
  2019-08-14  5:16   ` Christoph Hellwig
@ 2019-08-14  6:57     ` Wei Yang
  2019-08-14  9:19       ` Vlastimil Babka
  0 siblings, 1 reply; 13+ messages in thread
From: Wei Yang @ 2019-08-14  6:57 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Wei Yang, akpm, mgorman, vbabka, osalvador, linux-mm, linux-kernel

On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
>Btw, is there any good reason we don't use a list_head for vma linkage?

Not sure, maybe there is some historical reason?

-- 
Wei Yang
Help you, Help me


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

* Re: [PATCH 3/3] mm/mmap.c: extract __vma_unlink_list as counter part for __vma_link_list
  2019-08-14  6:57     ` Wei Yang
@ 2019-08-14  9:19       ` Vlastimil Babka
  2019-08-14 16:09         ` Wei Yang
  2019-08-20 17:26         ` Matthew Wilcox
  0 siblings, 2 replies; 13+ messages in thread
From: Vlastimil Babka @ 2019-08-14  9:19 UTC (permalink / raw)
  To: Wei Yang, Christoph Hellwig
  Cc: akpm, mgorman, osalvador, linux-mm, linux-kernel

On 8/14/19 8:57 AM, Wei Yang wrote:
> On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
>>Btw, is there any good reason we don't use a list_head for vma linkage?
> 
> Not sure, maybe there is some historical reason?

Seems it was single-linked until 2010 commit 297c5eee3724 ("mm: make the vma
list be doubly linked") and I guess it was just simpler to add the vm_prev link.

Conversion to list_head might be an interesting project for some "advanced
beginner" in the kernel :)



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

* Re: [PATCH 3/3] mm/mmap.c: extract __vma_unlink_list as counter part for __vma_link_list
  2019-08-14  9:19       ` Vlastimil Babka
@ 2019-08-14 16:09         ` Wei Yang
  2019-08-20 17:26         ` Matthew Wilcox
  1 sibling, 0 replies; 13+ messages in thread
From: Wei Yang @ 2019-08-14 16:09 UTC (permalink / raw)
  To: Vlastimil Babka
  Cc: Wei Yang, Christoph Hellwig, akpm, mgorman, osalvador, linux-mm,
	linux-kernel

On Wed, Aug 14, 2019 at 11:19:37AM +0200, Vlastimil Babka wrote:
>On 8/14/19 8:57 AM, Wei Yang wrote:
>> On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
>>>Btw, is there any good reason we don't use a list_head for vma linkage?
>> 
>> Not sure, maybe there is some historical reason?
>
>Seems it was single-linked until 2010 commit 297c5eee3724 ("mm: make the vma
>list be doubly linked") and I guess it was just simpler to add the vm_prev link.
>
>Conversion to list_head might be an interesting project for some "advanced
>beginner" in the kernel :)

Seems it will touch many code ...

-- 
Wei Yang
Help you, Help me


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

* Re: [PATCH 3/3] mm/mmap.c: extract __vma_unlink_list as counter part for __vma_link_list
  2019-08-14  9:19       ` Vlastimil Babka
  2019-08-14 16:09         ` Wei Yang
@ 2019-08-20 17:26         ` Matthew Wilcox
  2019-08-21  0:52           ` Wei Yang
  1 sibling, 1 reply; 13+ messages in thread
From: Matthew Wilcox @ 2019-08-20 17:26 UTC (permalink / raw)
  To: Vlastimil Babka
  Cc: Wei Yang, Christoph Hellwig, akpm, mgorman, osalvador, linux-mm,
	linux-kernel

On Wed, Aug 14, 2019 at 11:19:37AM +0200, Vlastimil Babka wrote:
> On 8/14/19 8:57 AM, Wei Yang wrote:
> > On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
> >>Btw, is there any good reason we don't use a list_head for vma linkage?
> > 
> > Not sure, maybe there is some historical reason?
> 
> Seems it was single-linked until 2010 commit 297c5eee3724 ("mm: make the vma
> list be doubly linked") and I guess it was just simpler to add the vm_prev link.
> 
> Conversion to list_head might be an interesting project for some "advanced
> beginner" in the kernel :)

I'm working to get rid of vm_prev and vm_next, so it would probably be
wasted effort.


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

* Re: [PATCH 3/3] mm/mmap.c: extract __vma_unlink_list as counter part for __vma_link_list
  2019-08-20 17:26         ` Matthew Wilcox
@ 2019-08-21  0:52           ` Wei Yang
  2019-08-21  0:54             ` Matthew Wilcox
  0 siblings, 1 reply; 13+ messages in thread
From: Wei Yang @ 2019-08-21  0:52 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Vlastimil Babka, Wei Yang, Christoph Hellwig, akpm, mgorman,
	osalvador, linux-mm, linux-kernel

On Tue, Aug 20, 2019 at 10:26:29AM -0700, Matthew Wilcox wrote:
>On Wed, Aug 14, 2019 at 11:19:37AM +0200, Vlastimil Babka wrote:
>> On 8/14/19 8:57 AM, Wei Yang wrote:
>> > On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
>> >>Btw, is there any good reason we don't use a list_head for vma linkage?
>> > 
>> > Not sure, maybe there is some historical reason?
>> 
>> Seems it was single-linked until 2010 commit 297c5eee3724 ("mm: make the vma
>> list be doubly linked") and I guess it was just simpler to add the vm_prev link.
>> 
>> Conversion to list_head might be an interesting project for some "advanced
>> beginner" in the kernel :)
>
>I'm working to get rid of vm_prev and vm_next, so it would probably be
>wasted effort.

You mean replace it with list_head?

-- 
Wei Yang
Help you, Help me


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

* Re: [PATCH 3/3] mm/mmap.c: extract __vma_unlink_list as counter part for __vma_link_list
  2019-08-21  0:52           ` Wei Yang
@ 2019-08-21  0:54             ` Matthew Wilcox
  2019-08-21  1:22               ` Wei Yang
  0 siblings, 1 reply; 13+ messages in thread
From: Matthew Wilcox @ 2019-08-21  0:54 UTC (permalink / raw)
  To: Wei Yang
  Cc: Vlastimil Babka, Christoph Hellwig, akpm, mgorman, osalvador,
	linux-mm, linux-kernel

On Wed, Aug 21, 2019 at 08:52:34AM +0800, Wei Yang wrote:
> On Tue, Aug 20, 2019 at 10:26:29AM -0700, Matthew Wilcox wrote:
> >On Wed, Aug 14, 2019 at 11:19:37AM +0200, Vlastimil Babka wrote:
> >> On 8/14/19 8:57 AM, Wei Yang wrote:
> >> > On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
> >> >>Btw, is there any good reason we don't use a list_head for vma linkage?
> >> > 
> >> > Not sure, maybe there is some historical reason?
> >> 
> >> Seems it was single-linked until 2010 commit 297c5eee3724 ("mm: make the vma
> >> list be doubly linked") and I guess it was just simpler to add the vm_prev link.
> >> 
> >> Conversion to list_head might be an interesting project for some "advanced
> >> beginner" in the kernel :)
> >
> >I'm working to get rid of vm_prev and vm_next, so it would probably be
> >wasted effort.
> 
> You mean replace it with list_head?

No, replace the rbtree with a new tree.  https://lwn.net/Articles/787629/


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

* Re: [PATCH 3/3] mm/mmap.c: extract __vma_unlink_list as counter part for __vma_link_list
  2019-08-21  0:54             ` Matthew Wilcox
@ 2019-08-21  1:22               ` Wei Yang
  2019-08-21  1:59                 ` Matthew Wilcox
  0 siblings, 1 reply; 13+ messages in thread
From: Wei Yang @ 2019-08-21  1:22 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Wei Yang, Vlastimil Babka, Christoph Hellwig, akpm, mgorman,
	osalvador, linux-mm, linux-kernel

On Tue, Aug 20, 2019 at 05:54:17PM -0700, Matthew Wilcox wrote:
>On Wed, Aug 21, 2019 at 08:52:34AM +0800, Wei Yang wrote:
>> On Tue, Aug 20, 2019 at 10:26:29AM -0700, Matthew Wilcox wrote:
>> >On Wed, Aug 14, 2019 at 11:19:37AM +0200, Vlastimil Babka wrote:
>> >> On 8/14/19 8:57 AM, Wei Yang wrote:
>> >> > On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
>> >> >>Btw, is there any good reason we don't use a list_head for vma linkage?
>> >> > 
>> >> > Not sure, maybe there is some historical reason?
>> >> 
>> >> Seems it was single-linked until 2010 commit 297c5eee3724 ("mm: make the vma
>> >> list be doubly linked") and I guess it was just simpler to add the vm_prev link.
>> >> 
>> >> Conversion to list_head might be an interesting project for some "advanced
>> >> beginner" in the kernel :)
>> >
>> >I'm working to get rid of vm_prev and vm_next, so it would probably be
>> >wasted effort.
>> 
>> You mean replace it with list_head?
>
>No, replace the rbtree with a new tree.  https://lwn.net/Articles/787629/

Sounds interesting.

While I am not sure the plan is settled down, and how long it would take to
replace the rb_tree with maple tree. I guess it would probably take some time
to get merged upstream.

IMHO, it would be good to have this cleanup in current kernel. Do you agree?

-- 
Wei Yang
Help you, Help me


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

* Re: [PATCH 3/3] mm/mmap.c: extract __vma_unlink_list as counter part for __vma_link_list
  2019-08-21  1:22               ` Wei Yang
@ 2019-08-21  1:59                 ` Matthew Wilcox
  2019-08-21  8:09                   ` Wei Yang
  0 siblings, 1 reply; 13+ messages in thread
From: Matthew Wilcox @ 2019-08-21  1:59 UTC (permalink / raw)
  To: Wei Yang
  Cc: Vlastimil Babka, Christoph Hellwig, akpm, mgorman, osalvador,
	linux-mm, linux-kernel

On Wed, Aug 21, 2019 at 09:22:44AM +0800, Wei Yang wrote:
> On Tue, Aug 20, 2019 at 05:54:17PM -0700, Matthew Wilcox wrote:
> >On Wed, Aug 21, 2019 at 08:52:34AM +0800, Wei Yang wrote:
> >> On Tue, Aug 20, 2019 at 10:26:29AM -0700, Matthew Wilcox wrote:
> >> >On Wed, Aug 14, 2019 at 11:19:37AM +0200, Vlastimil Babka wrote:
> >> >> On 8/14/19 8:57 AM, Wei Yang wrote:
> >> >> > On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
> >> >> >>Btw, is there any good reason we don't use a list_head for vma linkage?
> >> >> > 
> >> >> > Not sure, maybe there is some historical reason?
> >> >> 
> >> >> Seems it was single-linked until 2010 commit 297c5eee3724 ("mm: make the vma
> >> >> list be doubly linked") and I guess it was just simpler to add the vm_prev link.
> >> >> 
> >> >> Conversion to list_head might be an interesting project for some "advanced
> >> >> beginner" in the kernel :)
> >> >
> >> >I'm working to get rid of vm_prev and vm_next, so it would probably be
> >> >wasted effort.
> >> 
> >> You mean replace it with list_head?
> >
> >No, replace the rbtree with a new tree.  https://lwn.net/Articles/787629/
> 
> Sounds interesting.
> 
> While I am not sure the plan is settled down, and how long it would take to
> replace the rb_tree with maple tree. I guess it would probably take some time
> to get merged upstream.
> 
> IMHO, it would be good to have this cleanup in current kernel. Do you agree?

The three cleanups you've posted are fine.  Doing more work (ie the
list_head) seems like wasted effort to me.


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

* Re: [PATCH 3/3] mm/mmap.c: extract __vma_unlink_list as counter part for __vma_link_list
  2019-08-21  1:59                 ` Matthew Wilcox
@ 2019-08-21  8:09                   ` Wei Yang
  0 siblings, 0 replies; 13+ messages in thread
From: Wei Yang @ 2019-08-21  8:09 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Wei Yang, Vlastimil Babka, Christoph Hellwig, akpm, mgorman,
	osalvador, linux-mm, linux-kernel

On Tue, Aug 20, 2019 at 06:59:39PM -0700, Matthew Wilcox wrote:
>On Wed, Aug 21, 2019 at 09:22:44AM +0800, Wei Yang wrote:
>> On Tue, Aug 20, 2019 at 05:54:17PM -0700, Matthew Wilcox wrote:
>> >On Wed, Aug 21, 2019 at 08:52:34AM +0800, Wei Yang wrote:
>> >> On Tue, Aug 20, 2019 at 10:26:29AM -0700, Matthew Wilcox wrote:
>> >> >On Wed, Aug 14, 2019 at 11:19:37AM +0200, Vlastimil Babka wrote:
>> >> >> On 8/14/19 8:57 AM, Wei Yang wrote:
>> >> >> > On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
>> >> >> >>Btw, is there any good reason we don't use a list_head for vma linkage?
>> >> >> > 
>> >> >> > Not sure, maybe there is some historical reason?
>> >> >> 
>> >> >> Seems it was single-linked until 2010 commit 297c5eee3724 ("mm: make the vma
>> >> >> list be doubly linked") and I guess it was just simpler to add the vm_prev link.
>> >> >> 
>> >> >> Conversion to list_head might be an interesting project for some "advanced
>> >> >> beginner" in the kernel :)
>> >> >
>> >> >I'm working to get rid of vm_prev and vm_next, so it would probably be
>> >> >wasted effort.
>> >> 
>> >> You mean replace it with list_head?
>> >
>> >No, replace the rbtree with a new tree.  https://lwn.net/Articles/787629/
>> 
>> Sounds interesting.
>> 
>> While I am not sure the plan is settled down, and how long it would take to
>> replace the rb_tree with maple tree. I guess it would probably take some time
>> to get merged upstream.
>> 
>> IMHO, it would be good to have this cleanup in current kernel. Do you agree?
>
>The three cleanups you've posted are fine.  Doing more work (ie the
>list_head) seems like wasted effort to me.

Ah, got your point. I misunderstand it.

-- 
Wei Yang
Help you, Help me


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

end of thread, back to index

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-14  2:17 [PATCH 1/3] mm/mmap.c: prev could be retrieved from vma->vm_prev Wei Yang
2019-08-14  2:17 ` [PATCH 2/3] mm/mmap.c: __vma_unlink_prev is not necessary now Wei Yang
2019-08-14  2:17 ` [PATCH 3/3] mm/mmap.c: extract __vma_unlink_list as counter part for __vma_link_list Wei Yang
2019-08-14  5:16   ` Christoph Hellwig
2019-08-14  6:57     ` Wei Yang
2019-08-14  9:19       ` Vlastimil Babka
2019-08-14 16:09         ` Wei Yang
2019-08-20 17:26         ` Matthew Wilcox
2019-08-21  0:52           ` Wei Yang
2019-08-21  0:54             ` Matthew Wilcox
2019-08-21  1:22               ` Wei Yang
2019-08-21  1:59                 ` Matthew Wilcox
2019-08-21  8:09                   ` Wei Yang

Linux-mm Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \
		linux-mm@kvack.org linux-mm@archiver.kernel.org
	public-inbox-index linux-mm


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kvack.linux-mm


AGPL code for this site: git clone https://public-inbox.org/ public-inbox