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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx>
> 
> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/