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:

quoted

Mike Kravetz [off-list ref] writes:

quoted

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.

quoted

- 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, 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>