linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Matthew Wilcox <willy@linux.intel.com>, Jan Kara <jack@suse.cz>
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	lsf-pc@lists.linux-foundation.org
Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Support for 1GB THP
Date: Tue, 01 Mar 2016 17:33:01 -0500	[thread overview]
Message-ID: <1456871581.25322.62.camel@redhat.com> (raw)
In-Reply-To: <20160301214403.GJ3730@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]

On Tue, 2016-03-01 at 16:44 -0500, 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.

Given the amounts of memory in systems, and the fact
that 1TB (or even 2MB) page sizes will not always be
possible, even with DAX on persistent memory, I
suspect it may be time to implement the reclaiming of
page tables that only map file pages.

-- 
All Rights Reversed.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  parent reply	other threads:[~2016-03-01 22:33 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
2016-03-01 22:33     ` Rik van Riel [this message]
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=1456871581.25322.62.camel@redhat.com \
    --to=riel@redhat.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 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).