On Wed, Jan 08, 2014 at 03:13:21PM +0000, Mel Gorman wrote: > 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. Yes, performance data is critical. I'll try bring some. The only alternative I see is some kind of THP, implemented on filesystem level. It can work for tmpfs/shm reasonably well. But it looks ad-hoc and in long term transparent huge pagecache is the way to go, I believe. Sibling topic is THP for XIP (see Matthew's patchset). Guys want to manage persistent memory in 2M chunks where it's possible. And THP (but without struct page in this case) is the obvious solution. -- Kirill A. Shutemov -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>