On Thu, 18 Feb 2016, Kirill A. Shutemov wrote: > Hi, > > I would like to attend LSF/MM 2016. > > THP refcounting rework had been merged into v4.5 and I would like to > discuss next steps on THP front. > > == huge tmpfs == > > One of the topic would be huge tmpfs. Currently we have two alternative > implementation of huge pages support in tmpfs: > > - Hugh has implemented it on top of new way to couple pages together -- > team pages. It's rather mature implementation which has been used in > production. > > - I've implemented huge tmpfs on top of the same compound pages we use > for THP. It's still under validation and hasn't got proper review. > Few more iterations would be required to get it into shape. > > Supporting two parallel implementation of the same feature is wasteful. > During the summit I would like to work out a consensus on what > implementation fits upstream more. I would of course like to participate in this discussion too, if it works out to be a separate session from the Huge Page Futures session already proposed by Mike Kravetz. Though to judge from last year's experience, when I think neither Kirill nor I managed to engage the "audience" very much, I suspect we'll get more from our own face-to-face discussion and over email. But I can very well understand that Kirill would like to give me some kind of kick start, given that my contribution to that email has been nil so far over the last year. Hugh > > == khugepaged == > > Other topic I would like to talk about is khugepaged. New THP refcounting > opens some possibilities in this area. > > We've got split_huge_pmd() decoupled from splitting underlying compound > page. We can separate collapse into two stages too: first collapse small > pages into a huge one, and then replace PTE tables with PMDs where it's > possible. > > Even if the second stage has failed for some reason, we would still > benefit from fewer pages on LRU to deal with. > > It also allows to collapse pages shared over fork(), which we cannot do at > the moment. > > I personally would not have time to implement it any time soon, but I'll > help to anyone who wants to play with the idea. > > -- > 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>