Re: [LSF/MM ATTEND] Huge Page Futures

[Hugh Dickins <hughd@google.com>]

On Wed, 27 Jan 2016, Mike Kravetz wrote:
> On 01/25/2016 05:50 AM, Mike Kravetz wrote:
> > On 01/25/2016 03:01 AM, Kirill A. Shutemov wrote:
> >> On Sun, Jan 24, 2016 at 05:57:12PM -0800, Mike Kravetz wrote:
> >>> In a search of the archives, it appears huge page support in one form or
> >>> another has been a discussion topic in almost every LSF/MM gathering. Based
> >>> on patches submitted this past year, huge pages is still an area of active
> >>> development.  And, it appears this level of activity will  continue in the
> >>> coming year.
> >>>
> >>> I propose a "Huge Page Futures" session to discuss large works in progress
> >>> as well as work people are considering for 2016.  Areas of discussion would
> >>> minimally include:
> >>>
> >>> - Krill Shutemov's THP new refcounting code and the push for huge page
> >>>   support in the page cache.
> >>
> >> s/Krill/Kirill/ :]
> > 
> > Sorry!
> > 
> >>
> >> I work on huge pages in tmpfs first and will look on huge pages for real
> >> filesystems later.
> >>
> >>>
> >>> - Matt Wilcox's huge page support in DAX enabled filesystems, but perhaps
> >>>   more interesting is the desire for supporting PUD pages.  This seems to
> >>>   beg the question of supporting transparent PUD pages elsewhere.
> >>>
> >>> - Other suggestions?

I would like to attend LSF/MM 2016, and think I can contribute
to Mike's "Huge Page Futures" topic.  I remain very focussed on my
"huge tmpfs" THP pagecache implementation in tmpfs - which has proved
a success within Google over the last year - but hope that once I'm at
conference, can turn my attention to some of the other mm topics too.


> >>>
> >>> My interest in attending also revolves around huge pages.  This past year
> >>> I have added functionality to hugetlbfs.  hugetlbfs is not dead, and is
> >>> very much in use by some DB implementations.  Proposed future work I will
> >>> be attempting includes:
> >>> - Adding userfaultfd support to hugetlbfs
> >>> - Adding shared page table (PMD) support to DAX much like that which exists
> >>>   for hugetlbfs
> >>
> >> Shared page tables for hugetlbfs is rather ugly hack.
> >>
> >> Do you have any thoughts how it's going to be implemented? It would be
> >> nice to have some design overview or better proof-of-concept patch before
> >> the summit to be able analyze implications for the kernel.
> >>
> > 
> > Good to know the hugetlbfs implementation is considered a hack.  I just
> > started looking at this, and was going to use hugetlbfs as a starting
> > point.  I'll reconsider that decision.
> 
> Kirill, can you (or others) explain your reasons for saying the hugetlbfs
> implementation is an ugly hack?  I do not have enough history/experience
> with this to say what is most offensive.  I would be happy to start by
> cleaning up issues with the current implementation.

I disagree that the hugetlbfs shared pagetables are an ugly hack.
What they are is a dark backwater that very few people are aware of,
which we therefore can very easily break or be broken by.

I have regretted bringing them into mm for that reason, and have
thought that they're next in line for the axe, after those non-linear
vmas which Kirill dispatched without tears last year.  But if you're
intent on making more use of them, exposing them to the light of day
is a fair alternative to consider.

Hugh

> 
> If we do shared page tables for DAX, it makes sense that it and hugetlbfs
> should be similar (or common) if possible.
> 
> -- 
> Mike Kravetz
> 
> > 
> > BTW, this request comes from the same DB people taking advantage of shared
> > page tables today.  This will be as important (if not more) with the larger
> > sizes of pmem.

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>