From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mel Gorman Subject: Re: [Lsf-pc] [LSF/MM ATTEND] Memory management -- THP, hugetlb, scalability Date: Wed, 8 Jan 2014 15:13:21 +0000 Message-ID: <20140108151321.GI27046@suse.de> References: <20140103122509.GA18786@node.dhcp.inet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org To: "Kirill A. Shutemov" Return-path: Content-Disposition: inline In-Reply-To: <20140103122509.GA18786@node.dhcp.inet.fi> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Jan 03, 2014 at 02:25:09PM +0200, Kirill A. Shutemov wrote: > Hi, > > I would like to attend LSF/MM summit. I'm interested in discussion about > huge pages, scalability of memory management subsystem and persistent > memory. > > Last year I did some work to fix THP-related regressions and improve > scalability. I also work on THP for file-backed pages. > > Depending on project status, I probably want to bring transparent huge > pagecache as a topic. > I think transparent huge pagecache is likely to crop up for more than one reason. There is the TLB issue and the motivation that i-TLB pressure is a problem in some specialised cases. Whatever the merits of that case, transparent hugepage cache has been raised as a potential solution for some VM scalability problems. I recognise that dealing with large numbers of struct pages is now a problem on larger machines (although I have not seen quantified data on the problem nor do I have access to a machine large enough to measure it myself) but I'm wary of transparent hugepage cache being treated as a primary solution for VM scalability problems. Lacking performance data I have no suggestions on what these alternative solutions might look like. -- Mel Gorman SUSE Labs -- 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: email@kvack.org