From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [LSF/MM ATTEND] Huge Page Futures
Date: Mon, 25 Jan 2016 13:01:37 +0200 [thread overview]
Message-ID: <20160125110137.GB11541@node.shutemov.name> (raw)
In-Reply-To: <56A580F8.4060301@oracle.com>
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/ :]
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?
>
> 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.
--
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>
next prev parent reply other threads:[~2016-01-25 11:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-25 1:57 [LSF/MM ATTEND] Huge Page Futures Mike Kravetz
2016-01-25 11:01 ` Kirill A. Shutemov [this message]
2016-01-25 13:50 ` Mike Kravetz
2016-01-27 17:49 ` Mike Kravetz
2016-01-28 8:49 ` Hugh Dickins
2016-01-28 19:06 ` Mike Kravetz
2016-01-28 9:21 ` [Lsf-pc] " Mel Gorman
2016-01-28 18:24 ` Mike Kravetz
2016-01-28 15:05 ` Aneesh Kumar K.V
2016-01-28 19:28 ` Mike Kravetz
2016-01-29 10:01 ` Kirill A. Shutemov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160125110137.GB11541@node.shutemov.name \
--to=kirill@shutemov.name \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mike.kravetz@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).