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@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. > > 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@xxxxxxxxxx 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@xxxxxxxxx";> email@xxxxxxxxx </a>