From: Mike Kravetz <mike.kravetz@oracle.com>
To: Matthew Wilcox <willy@linux.intel.com>, Jan Kara <jack@suse.cz>
Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Support for 1GB THP
Date: Tue, 1 Mar 2016 14:15:03 -0800 [thread overview]
Message-ID: <56D61467.5000006@oracle.com> (raw)
In-Reply-To: <20160301214403.GJ3730@linux.intel.com>
On 03/01/2016 01:44 PM, Matthew Wilcox wrote:
> On Tue, Mar 01, 2016 at 11:25:41AM +0100, Jan Kara wrote:
>> On Tue 01-03-16 02:09:11, Matthew Wilcox wrote:
>>> There are a few issues around 1GB THP support that I've come up against
>>> while working on DAX support that I think may be interesting to discuss
>>> in person.
>>>
>>> - Do we want to add support for 1GB THP for anonymous pages? DAX support
>>> is driving the initial 1GB THP support, but would anonymous VMAs also
>>> benefit from 1GB support? I'm not volunteering to do this work, but
>>> it might make an interesting conversation if we can identify some users
>>> who think performance would be better if they had 1GB THP support.
>>
>> Some time ago I was thinking about 1GB THP and I was wondering: What is the
>> motivation for 1GB pages for persistent memory? Is it the savings in memory
>> used for page tables? Or is it about the cost of fault?
>
> I think it's both. I heard from one customer who calculated that with
> a 6TB server, mapping every page into a process would take ~24MB of
> page tables. Multiply that by the 50,000 processes they expect to run
> on a server of that size consumes 1.2TB of DRAM. Using 1GB pages reduces
> that by a factor of 512, down to 2GB.
>
> Another topic to consider then would be generalising the page table
> sharing code that is currently specific to hugetlbfs. I didn't bring
> it up as I haven't researched it in any detail, and don't know how hard
> it would be.
Well, I have started down that path and have it working for some very
simple cases with some very hacked up code. Too early/ugly to share.
I'm struggling a bit with fact that you can have both regular and huge
page mappings of the same regions. The hugetlb code only has to deal
with huge pages.
--
Mike Kravetz
--
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-03-01 22:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-01 7:09 [LSF/MM TOPIC] Support for 1GB THP Matthew Wilcox
2016-03-01 10:25 ` [Lsf-pc] " Jan Kara
2016-03-01 11:00 ` Mel Gorman
2016-03-01 11:51 ` Mel Gorman
2016-03-01 12:09 ` Kirill A. Shutemov
2016-03-01 12:52 ` Mel Gorman
2016-03-01 21:44 ` Matthew Wilcox
2016-03-01 22:15 ` Mike Kravetz [this message]
2016-03-01 22:33 ` Rik van Riel
2016-03-01 22:36 ` James Bottomley
2016-03-02 14:14 ` Matthew Wilcox
2016-03-01 12:20 ` Kirill A. Shutemov
2016-03-01 16:32 ` Christoph Lameter
2016-03-01 21:47 ` Matthew Wilcox
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=56D61467.5000006@oracle.com \
--to=mike.kravetz@oracle.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=willy@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.