Re: [Lsf-pc] [LSF/MM ATTEND] Memory management -- THP, hugetlb, scalability

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]