[PATCH] vmscan: move referenced VM_EXEC pages to active list

[PATCH] vmscan: move referenced VM_EXEC pages to active list

[Mandeep Singh Baines]

In commit 64574746, "vmscan: detect mapped file pages used only once",
Johannes Weiner, added logic to page_check_reference to cycle again
used once pages.

In commit 8cab4754, "vmscan: make mapped executable pages the first
class citizen", Wu Fengguang, added logic to shrink_active_list which
protects file-backed VM_EXEC pages by keeping them in the active_list if
they are referenced.

This patch adds logic to move such pages from the inactive list to the
active list immediately if they have been referenced. If a VM_EXEC page
is seen as referenced during an inactive list scan, that reference must
have occurred after the page was put on the inactive list. There is no
need to wait for the page to be referenced again.

Change-Id: I17c312e916377e93e5a92c52518b6c829f9ab30b
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
---
 mm/vmscan.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index c5dfabf..0984dee 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -593,6 +593,17 @@ static enum page_references page_check_references(struct page *page,
 	if (referenced_ptes) {
 		if (PageAnon(page))
 			return PAGEREF_ACTIVATE;
+
+		/*
+		 * Identify referenced, file-backed active pages and move them
+		 * to the active list. We know that this page has been
+		 * referenced since being put on the inactive list. VM_EXEC
+		 * pages are only moved to the inactive list when they have not
+		 * been referenced between scans (see shrink_active_list).
+		 */
+		if ((vm_flags & VM_EXEC) && page_is_file_cache(page))
+			return PAGEREF_ACTIVATE;
+
 		/*
 		 * All mapped pages start out with page table
 		 * references from the instantiating fault, so we need
-- 
1.7.1

[PATCH] vmscan: move referenced VM_EXEC pages to active list

[Mandeep Singh Baines]

In commit 64574746, "vmscan: detect mapped file pages used only once",
Johannes Weiner, added logic to page_check_reference to cycle again
used once pages.

In commit 8cab4754, "vmscan: make mapped executable pages the first
class citizen", Wu Fengguang, added logic to shrink_active_list which
protects file-backed VM_EXEC pages by keeping them in the active_list if
they are referenced.

This patch adds logic to move such pages from the inactive list to the
active list immediately if they have been referenced. If a VM_EXEC page
is seen as referenced during an inactive list scan, that reference must
have occurred after the page was put on the inactive list. There is no
need to wait for the page to be referenced again.

Change-Id: I17c312e916377e93e5a92c52518b6c829f9ab30b
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
---
 mm/vmscan.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index c5dfabf..0984dee 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -593,6 +593,17 @@ static enum page_references page_check_references(struct page *page,
 	if (referenced_ptes) {
 		if (PageAnon(page))
 			return PAGEREF_ACTIVATE;
+
+		/*
+		 * Identify referenced, file-backed active pages and move them
+		 * to the active list. We know that this page has been
+		 * referenced since being put on the inactive list. VM_EXEC
+		 * pages are only moved to the inactive list when they have not
+		 * been referenced between scans (see shrink_active_list).
+		 */
+		if ((vm_flags & VM_EXEC) && page_is_file_cache(page))
+			return PAGEREF_ACTIVATE;
+
 		/*
 		 * All mapped pages start out with page table
 		 * references from the instantiating fault, so we need
-- 
1.7.1

--
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>

Re: [PATCH] vmscan: move referenced VM_EXEC pages to active list

[Minchan Kim]

On Sat, Oct 23, 2010 at 7:51 AM, Mandeep Singh Baines <msb@chromium.org> wrote:
> In commit 64574746, "vmscan: detect mapped file pages used only once",
> Johannes Weiner, added logic to page_check_reference to cycle again
> used once pages.
>
> In commit 8cab4754, "vmscan: make mapped executable pages the first
> class citizen", Wu Fengguang, added logic to shrink_active_list which
> protects file-backed VM_EXEC pages by keeping them in the active_list if
> they are referenced.
>
> This patch adds logic to move such pages from the inactive list to the
> active list immediately if they have been referenced. If a VM_EXEC page
> is seen as referenced during an inactive list scan, that reference must
> have occurred after the page was put on the inactive list. There is no
> need to wait for the page to be referenced again.
>
> Change-Id: I17c312e916377e93e5a92c52518b6c829f9ab30b
> Signed-off-by: Mandeep Singh Baines <msb@chromium.org>

It seems to be similar to http://www.spinics.net/lists/linux-mm/msg09617.html.
I don't know what it is going. Shaohua?



-- 
Kind regards,
Minchan Kim

Re: [PATCH] vmscan: move referenced VM_EXEC pages to active list

[Minchan Kim]

On Sat, Oct 23, 2010 at 7:51 AM, Mandeep Singh Baines <msb@chromium.org> wrote:
> In commit 64574746, "vmscan: detect mapped file pages used only once",
> Johannes Weiner, added logic to page_check_reference to cycle again
> used once pages.
>
> In commit 8cab4754, "vmscan: make mapped executable pages the first
> class citizen", Wu Fengguang, added logic to shrink_active_list which
> protects file-backed VM_EXEC pages by keeping them in the active_list if
> they are referenced.
>
> This patch adds logic to move such pages from the inactive list to the
> active list immediately if they have been referenced. If a VM_EXEC page
> is seen as referenced during an inactive list scan, that reference must
> have occurred after the page was put on the inactive list. There is no
> need to wait for the page to be referenced again.
>
> Change-Id: I17c312e916377e93e5a92c52518b6c829f9ab30b
> Signed-off-by: Mandeep Singh Baines <msb@chromium.org>

It seems to be similar to http://www.spinics.net/lists/linux-mm/msg09617.html.
I don't know what it is going. Shaohua?



-- 
Kind regards,
Minchan Kim

--
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>

Re: [PATCH] vmscan: move referenced VM_EXEC pages to active list

[KOSAKI Motohiro]

> On Sat, Oct 23, 2010 at 7:51 AM, Mandeep Singh Baines <msb@chromium.org> wrote:
> > In commit 64574746, "vmscan: detect mapped file pages used only once",
> > Johannes Weiner, added logic to page_check_reference to cycle again
> > used once pages.
> >
> > In commit 8cab4754, "vmscan: make mapped executable pages the first
> > class citizen", Wu Fengguang, added logic to shrink_active_list which
> > protects file-backed VM_EXEC pages by keeping them in the active_list if
> > they are referenced.
> >
> > This patch adds logic to move such pages from the inactive list to the
> > active list immediately if they have been referenced. If a VM_EXEC page
> > is seen as referenced during an inactive list scan, that reference must
> > have occurred after the page was put on the inactive list. There is no
> > need to wait for the page to be referenced again.
> >
> > Change-Id: I17c312e916377e93e5a92c52518b6c829f9ab30b
> > Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
> 
> It seems to be similar to http://www.spinics.net/lists/linux-mm/msg09617.html.
> I don't know what it is going. Shaohua?

Hi Mandeep,

Yeah, if you have enough time, can you please consider to join this testing? or can you
please explain your interactivity experience if there is.

Thanks.

Re: [PATCH] vmscan: move referenced VM_EXEC pages to active list

[KOSAKI Motohiro]

> On Sat, Oct 23, 2010 at 7:51 AM, Mandeep Singh Baines <msb@chromium.org> wrote:
> > In commit 64574746, "vmscan: detect mapped file pages used only once",
> > Johannes Weiner, added logic to page_check_reference to cycle again
> > used once pages.
> >
> > In commit 8cab4754, "vmscan: make mapped executable pages the first
> > class citizen", Wu Fengguang, added logic to shrink_active_list which
> > protects file-backed VM_EXEC pages by keeping them in the active_list if
> > they are referenced.
> >
> > This patch adds logic to move such pages from the inactive list to the
> > active list immediately if they have been referenced. If a VM_EXEC page
> > is seen as referenced during an inactive list scan, that reference must
> > have occurred after the page was put on the inactive list. There is no
> > need to wait for the page to be referenced again.
> >
> > Change-Id: I17c312e916377e93e5a92c52518b6c829f9ab30b
> > Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
> 
> It seems to be similar to http://www.spinics.net/lists/linux-mm/msg09617.html.
> I don't know what it is going. Shaohua?

Hi Mandeep,

Yeah, if you have enough time, can you please consider to join this testing? or can you
please explain your interactivity experience if there is.

Thanks.




--
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>

Re: [PATCH] vmscan: move referenced VM_EXEC pages to active list

[Shaohua Li]

On Mon, 2010-10-25 at 06:52 +0800, Minchan Kim wrote:
> On Sat, Oct 23, 2010 at 7:51 AM, Mandeep Singh Baines <msb@chromium.org> wrote:
> > In commit 64574746, "vmscan: detect mapped file pages used only once",
> > Johannes Weiner, added logic to page_check_reference to cycle again
> > used once pages.
> >
> > In commit 8cab4754, "vmscan: make mapped executable pages the first
> > class citizen", Wu Fengguang, added logic to shrink_active_list which
> > protects file-backed VM_EXEC pages by keeping them in the active_list if
> > they are referenced.
> >
> > This patch adds logic to move such pages from the inactive list to the
> > active list immediately if they have been referenced. If a VM_EXEC page
> > is seen as referenced during an inactive list scan, that reference must
> > have occurred after the page was put on the inactive list. There is no
> > need to wait for the page to be referenced again.
> >
> > Change-Id: I17c312e916377e93e5a92c52518b6c829f9ab30b
> > Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
> 
> It seems to be similar to http://www.spinics.net/lists/linux-mm/msg09617.html.
> I don't know what it is going. Shaohua?
I should have sent the test result earlier but was offlined last week.
Here is my test result:
kernel1: base kernel + revert commit 8cab4754
kernel2: base kernel
kernel3: base kernel + my patch (similar like Mandeep's)
I'm using Fengguang's test of commit 8cab4754. But the test result isn't
stable, sometimes one kernel above has more majfault, but sometimes the
kernel has less majfault. This is true for all the above kernels.
Apparently kernel behavior changes (guess because of commit 64574746),
and vm_exec protect (even the vm_exec protect in active list) is not
important now with new kernel in Fengguang's test suite.

But on the other hand, if I add a new task into Fengguang's test suite.
The task produces a lot of used one file page read (sequential read a
large sparse file). Kernel2 has less majfault than kernel1, and kernel3
has even less majfault than kernel2, so kernel3 has best performance.
Basically the majfault number from kernel1 is 3x, kernel2 2x, kernel3
1x. One issue is I'm afraid this isn't a typical desktop usage any more
(because of sequential read sparse file), so not sure if we can use this
test as a judgment to merge the patch.

Thanks,
Shaohua

Re: [PATCH] vmscan: move referenced VM_EXEC pages to active list

[Shaohua Li]

On Mon, 2010-10-25 at 06:52 +0800, Minchan Kim wrote:
> On Sat, Oct 23, 2010 at 7:51 AM, Mandeep Singh Baines <msb@chromium.org> wrote:
> > In commit 64574746, "vmscan: detect mapped file pages used only once",
> > Johannes Weiner, added logic to page_check_reference to cycle again
> > used once pages.
> >
> > In commit 8cab4754, "vmscan: make mapped executable pages the first
> > class citizen", Wu Fengguang, added logic to shrink_active_list which
> > protects file-backed VM_EXEC pages by keeping them in the active_list if
> > they are referenced.
> >
> > This patch adds logic to move such pages from the inactive list to the
> > active list immediately if they have been referenced. If a VM_EXEC page
> > is seen as referenced during an inactive list scan, that reference must
> > have occurred after the page was put on the inactive list. There is no
> > need to wait for the page to be referenced again.
> >
> > Change-Id: I17c312e916377e93e5a92c52518b6c829f9ab30b
> > Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
> 
> It seems to be similar to http://www.spinics.net/lists/linux-mm/msg09617.html.
> I don't know what it is going. Shaohua?
I should have sent the test result earlier but was offlined last week.
Here is my test result:
kernel1: base kernel + revert commit 8cab4754
kernel2: base kernel
kernel3: base kernel + my patch (similar like Mandeep's)
I'm using Fengguang's test of commit 8cab4754. But the test result isn't
stable, sometimes one kernel above has more majfault, but sometimes the
kernel has less majfault. This is true for all the above kernels.
Apparently kernel behavior changes (guess because of commit 64574746),
and vm_exec protect (even the vm_exec protect in active list) is not
important now with new kernel in Fengguang's test suite.

But on the other hand, if I add a new task into Fengguang's test suite.
The task produces a lot of used one file page read (sequential read a
large sparse file). Kernel2 has less majfault than kernel1, and kernel3
has even less majfault than kernel2, so kernel3 has best performance.
Basically the majfault number from kernel1 is 3x, kernel2 2x, kernel3
1x. One issue is I'm afraid this isn't a typical desktop usage any more
(because of sequential read sparse file), so not sure if we can use this
test as a judgment to merge the patch.

Thanks,
Shaohua

--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] vmscan: move referenced VM_EXEC pages to active list

[Minchan Kim]

On Sun, Oct 31, 2010 at 11:58:52AM +0800, Shaohua Li wrote:
> On Mon, 2010-10-25 at 06:52 +0800, Minchan Kim wrote:
> > On Sat, Oct 23, 2010 at 7:51 AM, Mandeep Singh Baines <msb@chromium.org> wrote:
> > > In commit 64574746, "vmscan: detect mapped file pages used only once",
> > > Johannes Weiner, added logic to page_check_reference to cycle again
> > > used once pages.
> > >
> > > In commit 8cab4754, "vmscan: make mapped executable pages the first
> > > class citizen", Wu Fengguang, added logic to shrink_active_list which
> > > protects file-backed VM_EXEC pages by keeping them in the active_list if
> > > they are referenced.
> > >
> > > This patch adds logic to move such pages from the inactive list to the
> > > active list immediately if they have been referenced. If a VM_EXEC page
> > > is seen as referenced during an inactive list scan, that reference must
> > > have occurred after the page was put on the inactive list. There is no
> > > need to wait for the page to be referenced again.
> > >
> > > Change-Id: I17c312e916377e93e5a92c52518b6c829f9ab30b
> > > Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
> > 
> > It seems to be similar to http://www.spinics.net/lists/linux-mm/msg09617.html.
> > I don't know what it is going. Shaohua?
> I should have sent the test result earlier but was offlined last week.
> Here is my test result:
> kernel1: base kernel + revert commit 8cab4754
> kernel2: base kernel
> kernel3: base kernel + my patch (similar like Mandeep's)
> I'm using Fengguang's test of commit 8cab4754. But the test result isn't
> stable, sometimes one kernel above has more majfault, but sometimes the
> kernel has less majfault. This is true for all the above kernels.
> Apparently kernel behavior changes (guess because of commit 64574746),
> and vm_exec protect (even the vm_exec protect in active list) is not
> important now with new kernel in Fengguang's test suite.

Tend to agree.
When I saw 64574746, I doubted 8cab4754's effectiveness.
When we reviewed 8cab4754, there were many discussion. 
The thing I kept my mind was a trick of VM_EXEC.
Someone can whip LRU by VM_EXEC hack intentionally.
Apparently, It's bad. 

> 
> But on the other hand, if I add a new task into Fengguang's test suite.
> The task produces a lot of used one file page read (sequential read a
> large sparse file). Kernel2 has less majfault than kernel1, and kernel3
> has even less majfault than kernel2, so kernel3 has best performance.
> Basically the majfault number from kernel1 is 3x, kernel2 2x, kernel3
> 1x. One issue is I'm afraid this isn't a typical desktop usage any more
> (because of sequential read sparse file), so not sure if we can use this
> test as a judgment to merge the patch.

We can't make sure desktop doesn't has such workload and server also can have
such workload. I mean if it enhance VM by general POV, we can merge it enoughly.
In your testcase, Removing VM_EXEC test(ie, kernel 2) doesn't have biased.
It means it's not the best but not worst, either. 
Although we can't get the best, we can remove VM_EXEC hack. It's not a bad deal.
So how about removing VM_EXEC hack in this chance?

I hope we revert VM_EXEC hack in this chance.
Of course, before we discuss it, we can need more and detail data.
I hope you could help for the number.

Thanks, Shaohua.

-- 
Kind regards,
Minchan Kim

Re: [PATCH] vmscan: move referenced VM_EXEC pages to active list

[Minchan Kim]

On Sun, Oct 31, 2010 at 11:58:52AM +0800, Shaohua Li wrote:
> On Mon, 2010-10-25 at 06:52 +0800, Minchan Kim wrote:
> > On Sat, Oct 23, 2010 at 7:51 AM, Mandeep Singh Baines <msb@chromium.org> wrote:
> > > In commit 64574746, "vmscan: detect mapped file pages used only once",
> > > Johannes Weiner, added logic to page_check_reference to cycle again
> > > used once pages.
> > >
> > > In commit 8cab4754, "vmscan: make mapped executable pages the first
> > > class citizen", Wu Fengguang, added logic to shrink_active_list which
> > > protects file-backed VM_EXEC pages by keeping them in the active_list if
> > > they are referenced.
> > >
> > > This patch adds logic to move such pages from the inactive list to the
> > > active list immediately if they have been referenced. If a VM_EXEC page
> > > is seen as referenced during an inactive list scan, that reference must
> > > have occurred after the page was put on the inactive list. There is no
> > > need to wait for the page to be referenced again.
> > >
> > > Change-Id: I17c312e916377e93e5a92c52518b6c829f9ab30b
> > > Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
> > 
> > It seems to be similar to http://www.spinics.net/lists/linux-mm/msg09617.html.
> > I don't know what it is going. Shaohua?
> I should have sent the test result earlier but was offlined last week.
> Here is my test result:
> kernel1: base kernel + revert commit 8cab4754
> kernel2: base kernel
> kernel3: base kernel + my patch (similar like Mandeep's)
> I'm using Fengguang's test of commit 8cab4754. But the test result isn't
> stable, sometimes one kernel above has more majfault, but sometimes the
> kernel has less majfault. This is true for all the above kernels.
> Apparently kernel behavior changes (guess because of commit 64574746),
> and vm_exec protect (even the vm_exec protect in active list) is not
> important now with new kernel in Fengguang's test suite.

Tend to agree.
When I saw 64574746, I doubted 8cab4754's effectiveness.
When we reviewed 8cab4754, there were many discussion. 
The thing I kept my mind was a trick of VM_EXEC.
Someone can whip LRU by VM_EXEC hack intentionally.
Apparently, It's bad. 

> 
> But on the other hand, if I add a new task into Fengguang's test suite.
> The task produces a lot of used one file page read (sequential read a
> large sparse file). Kernel2 has less majfault than kernel1, and kernel3
> has even less majfault than kernel2, so kernel3 has best performance.
> Basically the majfault number from kernel1 is 3x, kernel2 2x, kernel3
> 1x. One issue is I'm afraid this isn't a typical desktop usage any more
> (because of sequential read sparse file), so not sure if we can use this
> test as a judgment to merge the patch.

We can't make sure desktop doesn't has such workload and server also can have
such workload. I mean if it enhance VM by general POV, we can merge it enoughly.
In your testcase, Removing VM_EXEC test(ie, kernel 2) doesn't have biased.
It means it's not the best but not worst, either. 
Although we can't get the best, we can remove VM_EXEC hack. It's not a bad deal.
So how about removing VM_EXEC hack in this chance?

I hope we revert VM_EXEC hack in this chance.
Of course, before we discuss it, we can need more and detail data.
I hope you could help for the number.

Thanks, Shaohua.

-- 
Kind regards,
Minchan Kim

--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] vmscan: move referenced VM_EXEC pages to active list

[Shaohua Li]

On Mon, 2010-11-01 at 21:41 +0800, Minchan Kim wrote:
> On Sun, Oct 31, 2010 at 11:58:52AM +0800, Shaohua Li wrote:
> > On Mon, 2010-10-25 at 06:52 +0800, Minchan Kim wrote:
> > > On Sat, Oct 23, 2010 at 7:51 AM, Mandeep Singh Baines <msb@chromium.org> wrote:
> > > > In commit 64574746, "vmscan: detect mapped file pages used only once",
> > > > Johannes Weiner, added logic to page_check_reference to cycle again
> > > > used once pages.
> > > >
> > > > In commit 8cab4754, "vmscan: make mapped executable pages the first
> > > > class citizen", Wu Fengguang, added logic to shrink_active_list which
> > > > protects file-backed VM_EXEC pages by keeping them in the active_list if
> > > > they are referenced.
> > > >
> > > > This patch adds logic to move such pages from the inactive list to the
> > > > active list immediately if they have been referenced. If a VM_EXEC page
> > > > is seen as referenced during an inactive list scan, that reference must
> > > > have occurred after the page was put on the inactive list. There is no
> > > > need to wait for the page to be referenced again.
> > > >
> > > > Change-Id: I17c312e916377e93e5a92c52518b6c829f9ab30b
> > > > Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
> > > 
> > > It seems to be similar to http://www.spinics.net/lists/linux-mm/msg09617.html.
> > > I don't know what it is going. Shaohua?
> > I should have sent the test result earlier but was offlined last week.
> > Here is my test result:
> > kernel1: base kernel + revert commit 8cab4754
> > kernel2: base kernel
> > kernel3: base kernel + my patch (similar like Mandeep's)
> > I'm using Fengguang's test of commit 8cab4754. But the test result isn't
> > stable, sometimes one kernel above has more majfault, but sometimes the
> > kernel has less majfault. This is true for all the above kernels.
> > Apparently kernel behavior changes (guess because of commit 64574746),
> > and vm_exec protect (even the vm_exec protect in active list) is not
> > important now with new kernel in Fengguang's test suite.
> 
> Tend to agree.
> When I saw 64574746, I doubted 8cab4754's effectiveness.
> When we reviewed 8cab4754, there were many discussion. 
> The thing I kept my mind was a trick of VM_EXEC.
> Someone can whip LRU by VM_EXEC hack intentionally.
> Apparently, It's bad. 
> 
> > 
> > But on the other hand, if I add a new task into Fengguang's test suite.
> > The task produces a lot of used one file page read (sequential read a
> > large sparse file). Kernel2 has less majfault than kernel1, and kernel3
> > has even less majfault than kernel2, so kernel3 has best performance.
> > Basically the majfault number from kernel1 is 3x, kernel2 2x, kernel3
> > 1x. One issue is I'm afraid this isn't a typical desktop usage any more
> > (because of sequential read sparse file), so not sure if we can use this
> > test as a judgment to merge the patch.
> 
> We can't make sure desktop doesn't has such workload and server also can have
> such workload. I mean if it enhance VM by general POV, we can merge it enoughly.
> In your testcase, Removing VM_EXEC test(ie, kernel 2) doesn't have biased.
> It means it's not the best but not worst, either. 
> Although we can't get the best, we can remove VM_EXEC hack. It's not a bad deal.
> So how about removing VM_EXEC hack in this chance?
> 
> I hope we revert VM_EXEC hack in this chance.
> Of course, before we discuss it, we can need more and detail data.
> I hope you could help for the number.
I'm thinking if we should revert VM_EXEC hack too. The headache is we
need find a typical workload which can convince people and get number
under the workload. Fengguang's test case hasn't enough non vm_exec file
pages I think.

Thanks,
Shaohua

Re: [PATCH] vmscan: move referenced VM_EXEC pages to active list

[Shaohua Li]

On Mon, 2010-11-01 at 21:41 +0800, Minchan Kim wrote:
> On Sun, Oct 31, 2010 at 11:58:52AM +0800, Shaohua Li wrote:
> > On Mon, 2010-10-25 at 06:52 +0800, Minchan Kim wrote:
> > > On Sat, Oct 23, 2010 at 7:51 AM, Mandeep Singh Baines <msb@chromium.org> wrote:
> > > > In commit 64574746, "vmscan: detect mapped file pages used only once",
> > > > Johannes Weiner, added logic to page_check_reference to cycle again
> > > > used once pages.
> > > >
> > > > In commit 8cab4754, "vmscan: make mapped executable pages the first
> > > > class citizen", Wu Fengguang, added logic to shrink_active_list which
> > > > protects file-backed VM_EXEC pages by keeping them in the active_list if
> > > > they are referenced.
> > > >
> > > > This patch adds logic to move such pages from the inactive list to the
> > > > active list immediately if they have been referenced. If a VM_EXEC page
> > > > is seen as referenced during an inactive list scan, that reference must
> > > > have occurred after the page was put on the inactive list. There is no
> > > > need to wait for the page to be referenced again.
> > > >
> > > > Change-Id: I17c312e916377e93e5a92c52518b6c829f9ab30b
> > > > Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
> > > 
> > > It seems to be similar to http://www.spinics.net/lists/linux-mm/msg09617.html.
> > > I don't know what it is going. Shaohua?
> > I should have sent the test result earlier but was offlined last week.
> > Here is my test result:
> > kernel1: base kernel + revert commit 8cab4754
> > kernel2: base kernel
> > kernel3: base kernel + my patch (similar like Mandeep's)
> > I'm using Fengguang's test of commit 8cab4754. But the test result isn't
> > stable, sometimes one kernel above has more majfault, but sometimes the
> > kernel has less majfault. This is true for all the above kernels.
> > Apparently kernel behavior changes (guess because of commit 64574746),
> > and vm_exec protect (even the vm_exec protect in active list) is not
> > important now with new kernel in Fengguang's test suite.
> 
> Tend to agree.
> When I saw 64574746, I doubted 8cab4754's effectiveness.
> When we reviewed 8cab4754, there were many discussion. 
> The thing I kept my mind was a trick of VM_EXEC.
> Someone can whip LRU by VM_EXEC hack intentionally.
> Apparently, It's bad. 
> 
> > 
> > But on the other hand, if I add a new task into Fengguang's test suite.
> > The task produces a lot of used one file page read (sequential read a
> > large sparse file). Kernel2 has less majfault than kernel1, and kernel3
> > has even less majfault than kernel2, so kernel3 has best performance.
> > Basically the majfault number from kernel1 is 3x, kernel2 2x, kernel3
> > 1x. One issue is I'm afraid this isn't a typical desktop usage any more
> > (because of sequential read sparse file), so not sure if we can use this
> > test as a judgment to merge the patch.
> 
> We can't make sure desktop doesn't has such workload and server also can have
> such workload. I mean if it enhance VM by general POV, we can merge it enoughly.
> In your testcase, Removing VM_EXEC test(ie, kernel 2) doesn't have biased.
> It means it's not the best but not worst, either. 
> Although we can't get the best, we can remove VM_EXEC hack. It's not a bad deal.
> So how about removing VM_EXEC hack in this chance?
> 
> I hope we revert VM_EXEC hack in this chance.
> Of course, before we discuss it, we can need more and detail data.
> I hope you could help for the number.
I'm thinking if we should revert VM_EXEC hack too. The headache is we
need find a typical workload which can convince people and get number
under the workload. Fengguang's test case hasn't enough non vm_exec file
pages I think.

Thanks,
Shaohua

--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] vmscan: move referenced VM_EXEC pages to active list

[Mandeep Singh Baines]

In commit 64574746, "vmscan: detect mapped file pages used only once",
Johannes Weiner, added logic to page_check_reference to cycle again
used once pages.

In commit 8cab4754, "vmscan: make mapped executable pages the first
class citizen", Wu Fengguang, added logic to shrink_active_list which
protects file-backed VM_EXEC pages by keeping them in the active_list if
they are referenced.

This patch adds logic to move such pages from the inactive list to the
active list immediately if they have been referenced. If a VM_EXEC page
is seen as referenced during an inactive list scan, that reference must
have occurred after the page was put on the inactive list. There is no
need to wait for the page to be referenced again.

Change-Id: I17c312e916377e93e5a92c52518b6c829f9ab30b
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
---
 mm/vmscan.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index c5dfabf..0984dee 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -593,6 +593,17 @@ static enum page_references page_check_references(struct page *page,
 	if (referenced_ptes) {
 		if (PageAnon(page))
 			return PAGEREF_ACTIVATE;
+
+		/*
+		 * Identify referenced, file-backed active pages and move them
+		 * to the active list. We know that this page has been
+		 * referenced since being put on the inactive list. VM_EXEC
+		 * pages are only moved to the inactive list when they have not
+		 * been referenced between scans (see shrink_active_list).
+		 */
+		if ((vm_flags & VM_EXEC) && page_is_file_cache(page))
+			return PAGEREF_ACTIVATE;
+
 		/*
 		 * All mapped pages start out with page table
 		 * references from the instantiating fault, so we need
-- 
1.7.1

[PATCH] vmscan: move referenced VM_EXEC pages to active list

[Mandeep Singh Baines]

In commit 64574746, "vmscan: detect mapped file pages used only once",
Johannes Weiner, added logic to page_check_reference to cycle again
used once pages.

In commit 8cab4754, "vmscan: make mapped executable pages the first
class citizen", Wu Fengguang, added logic to shrink_active_list which
protects file-backed VM_EXEC pages by keeping them in the active_list if
they are referenced.

This patch adds logic to move such pages from the inactive list to the
active list immediately if they have been referenced. If a VM_EXEC page
is seen as referenced during an inactive list scan, that reference must
have occurred after the page was put on the inactive list. There is no
need to wait for the page to be referenced again.

Change-Id: I17c312e916377e93e5a92c52518b6c829f9ab30b
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
---
 mm/vmscan.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index c5dfabf..0984dee 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -593,6 +593,17 @@ static enum page_references page_check_references(struct page *page,
 	if (referenced_ptes) {
 		if (PageAnon(page))
 			return PAGEREF_ACTIVATE;
+
+		/*
+		 * Identify referenced, file-backed active pages and move them
+		 * to the active list. We know that this page has been
+		 * referenced since being put on the inactive list. VM_EXEC
+		 * pages are only moved to the inactive list when they have not
+		 * been referenced between scans (see shrink_active_list).
+		 */
+		if ((vm_flags & VM_EXEC) && page_is_file_cache(page))
+			return PAGEREF_ACTIVATE;
+
 		/*
 		 * All mapped pages start out with page table
 		 * references from the instantiating fault, so we need
-- 
1.7.1

--
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>