On Thu, Jan 28, 2016 at 11:28:33AM -0800, Mike Kravetz wrote: > On 01/28/2016 07:05 AM, Aneesh Kumar K.V wrote: > > Mike Kravetz <mike.kravetz@xxxxxxxxxx> writes: > > > >> 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. > > > > I am also interested in this discussion. We had some nice challenge > > w.r.t to powerpc implementation of THP. > > > >> > >> - 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. > >> > > > > I am also looking at switching powerpc hugetlbfs to GENERAL_HUGETLB. To > > support 16GB pages I would need hugepage at PUD/PGD. Can you elaborate > > why supporting huge PUD page is a challenge ? > > For hugetlbfs it should not be an issue. However, page fault handling for > hugetlbfs is already a special case today. Is that what you were asking? > > Matt's work adds THP for PUD sized huge pages to DAX mappings. The thought > that popped into my head is "Does it make sense to try and expand THP for > PUD sized pages elsewhere?". Perhaps that is nonsense and a silly question > to ask. I don't think it has much sense on x86-64. But if an architecture has more reasonable page size on PUD level, who knows... -- Kirill A. Shutemov -- 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
