linux-kernel - Re: [PATCH] vmscan: move referenced VM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 02 Nov 2010 08:31:10 +0800
From:	Shaohua Li <shaohua.li@...el.com>
To:	Minchan Kim <minchan.kim@...il.com>
Cc:	Mandeep Singh Baines <msb@...omium.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Rik van Riel <riel@...hat.com>, Mel Gorman <mel@....ul.ie>,
	Johannes Weiner <hannes@...xchg.org>,
	"Wu, Fengguang" <fengguang.wu@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"wad@...omium.org" <wad@...omium.org>,
	"olofj@...omium.org" <olofj@...omium.org>
Subject: Re: [PATCH] vmscan: move referenced VM_EXEC pages to active list

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