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 from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
