From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Theodore Ts'o <tytso@mit.edu>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Christoph Hellwig <hch@lst.de>,
Dan Williams <dan.j.williams@intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Ingo Molnar <mingo@redhat.com>, Jan Kara <jack@suse.cz>,
Jonathan Corbet <corbet@lwn.net>,
Matthew Wilcox <mawilcox@microsoft.com>,
Steven Rostedt <rostedt@goodmis.org>,
linux-doc@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-nvdimm@lists.01.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH v3 0/5] DAX common 4k zero page
Date: Fri, 30 Jun 2017 13:05:56 -0600 [thread overview]
Message-ID: <20170630190556.GB27371@linux.intel.com> (raw)
In-Reply-To: <20170628220152.28161-1-ross.zwisler@linux.intel.com>
On Wed, Jun 28, 2017 at 04:01:47PM -0600, Ross Zwisler wrote:
> When servicing mmap() reads from file holes the current DAX code allocates
> a page cache page of all zeroes and places the struct page pointer in the
> mapping->page_tree radix tree. This has three major drawbacks:
>
> 1) It consumes memory unnecessarily. For every 4k page that is read via a
> DAX mmap() over a hole, we allocate a new page cache page. This means that
> if you read 1GiB worth of pages, you end up using 1GiB of zeroed memory.
>
> 2) It is slower than using a common zero page because each page fault has
> more work to do. Instead of just inserting a common zero page we have to
> allocate a page cache page, zero it, and then insert it.
>
> 3) The fact that we had to check for both DAX exceptional entries and for
> page cache pages in the radix tree made the DAX code more complex.
>
> This series solves these issues by following the lead of the DAX PMD code
> and using a common 4k zero page instead. This reduces memory usage and
> decreases latencies for some workloads, and it simplifies the DAX code,
> removing over 100 lines in total.
>
> Andrew, I'm still hoping to get this merged for v4.13 if possible. I I have
> addressed all of Jan's feedback, but he is on vacation for the next few
> weeks so he may not be able to give me Reviewed-by tags. I think this
> series is relatively low risk with clear benefits, and I think we should be
> able to address any issues that come up during the v4.13 RC series.
>
> This series has passed my targeted testing and a full xfstests run on both
> XFS and ext4.
This series has also passed the automated 0-day kernel builds in 168 configs.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: linux-xfs@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
Matthew Wilcox <mawilcox@microsoft.com>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Jonathan Corbet <corbet@lwn.net>,
linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
linux-doc@vger.kernel.org, linux-mm@kvack.org,
Dave Hansen <dave.hansen@intel.com>,
Ingo Molnar <mingo@redhat.com>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, Jan Kara <jack@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
linux-ext4@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
linux-nvdimm@lists.01.org
Subject: Re: [PATCH v3 0/5] DAX common 4k zero page
Date: Fri, 30 Jun 2017 13:05:56 -0600 [thread overview]
Message-ID: <20170630190556.GB27371@linux.intel.com> (raw)
In-Reply-To: <20170628220152.28161-1-ross.zwisler@linux.intel.com>
On Wed, Jun 28, 2017 at 04:01:47PM -0600, Ross Zwisler wrote:
> When servicing mmap() reads from file holes the current DAX code allocates
> a page cache page of all zeroes and places the struct page pointer in the
> mapping->page_tree radix tree. This has three major drawbacks:
>
> 1) It consumes memory unnecessarily. For every 4k page that is read via a
> DAX mmap() over a hole, we allocate a new page cache page. This means that
> if you read 1GiB worth of pages, you end up using 1GiB of zeroed memory.
>
> 2) It is slower than using a common zero page because each page fault has
> more work to do. Instead of just inserting a common zero page we have to
> allocate a page cache page, zero it, and then insert it.
>
> 3) The fact that we had to check for both DAX exceptional entries and for
> page cache pages in the radix tree made the DAX code more complex.
>
> This series solves these issues by following the lead of the DAX PMD code
> and using a common 4k zero page instead. This reduces memory usage and
> decreases latencies for some workloads, and it simplifies the DAX code,
> removing over 100 lines in total.
>
> Andrew, I'm still hoping to get this merged for v4.13 if possible. I I have
> addressed all of Jan's feedback, but he is on vacation for the next few
> weeks so he may not be able to give me Reviewed-by tags. I think this
> series is relatively low risk with clear benefits, and I think we should be
> able to address any issues that come up during the v4.13 RC series.
>
> This series has passed my targeted testing and a full xfstests run on both
> XFS and ext4.
This series has also passed the automated 0-day kernel builds in 168 configs.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Theodore Ts'o <tytso@mit.edu>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Christoph Hellwig <hch@lst.de>,
Dan Williams <dan.j.williams@intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Ingo Molnar <mingo@redhat.com>, Jan Kara <jack@suse.cz>,
Jonathan Corbet <corbet@lwn.net>,
Matthew Wilcox <mawilcox@microsoft.com>,
Steven Rostedt <rostedt@goodmis.org>,
linux-doc@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-nvdimm@lists.01.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH v3 0/5] DAX common 4k zero page
Date: Fri, 30 Jun 2017 13:05:56 -0600 [thread overview]
Message-ID: <20170630190556.GB27371@linux.intel.com> (raw)
In-Reply-To: <20170628220152.28161-1-ross.zwisler@linux.intel.com>
On Wed, Jun 28, 2017 at 04:01:47PM -0600, Ross Zwisler wrote:
> When servicing mmap() reads from file holes the current DAX code allocates
> a page cache page of all zeroes and places the struct page pointer in the
> mapping->page_tree radix tree. This has three major drawbacks:
>
> 1) It consumes memory unnecessarily. For every 4k page that is read via a
> DAX mmap() over a hole, we allocate a new page cache page. This means that
> if you read 1GiB worth of pages, you end up using 1GiB of zeroed memory.
>
> 2) It is slower than using a common zero page because each page fault has
> more work to do. Instead of just inserting a common zero page we have to
> allocate a page cache page, zero it, and then insert it.
>
> 3) The fact that we had to check for both DAX exceptional entries and for
> page cache pages in the radix tree made the DAX code more complex.
>
> This series solves these issues by following the lead of the DAX PMD code
> and using a common 4k zero page instead. This reduces memory usage and
> decreases latencies for some workloads, and it simplifies the DAX code,
> removing over 100 lines in total.
>
> Andrew, I'm still hoping to get this merged for v4.13 if possible. I I have
> addressed all of Jan's feedback, but he is on vacation for the next few
> weeks so he may not be able to give me Reviewed-by tags. I think this
> series is relatively low risk with clear benefits, and I think we should be
> able to address any issues that come up during the v4.13 RC series.
>
> This series has passed my targeted testing and a full xfstests run on both
> XFS and ext4.
This series has also passed the automated 0-day kernel builds in 168 configs.
next prev parent reply other threads:[~2017-06-30 19:05 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-28 22:01 [PATCH v3 0/5] DAX common 4k zero page Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
[not found] ` <20170628220152.28161-1-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-06-28 22:01 ` [PATCH v3 1/5] mm: add vm_insert_mixed_mkwrite() Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
2017-07-19 14:16 ` Jan Kara
2017-07-19 14:16 ` Jan Kara
[not found] ` <20170719141659.GB15908-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
2017-07-19 17:51 ` Ross Zwisler
2017-07-19 17:51 ` Ross Zwisler
2017-07-19 17:51 ` Ross Zwisler
2017-07-19 17:51 ` Ross Zwisler
[not found] ` <20170719175112.GA24588-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-07-19 21:58 ` Ross Zwisler
2017-07-19 21:58 ` Ross Zwisler
2017-07-19 21:58 ` Ross Zwisler
2017-07-19 21:58 ` Ross Zwisler
2017-07-21 17:44 ` Ross Zwisler
2017-07-21 17:44 ` Ross Zwisler
2017-07-21 17:44 ` Ross Zwisler
2017-07-24 11:20 ` Jan Kara
2017-07-24 11:20 ` Jan Kara
2017-07-24 11:20 ` Jan Kara
[not found] ` <20170628220152.28161-2-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-07-20 15:26 ` Vivek Goyal
2017-07-20 15:26 ` Vivek Goyal
2017-07-20 15:26 ` Vivek Goyal
2017-07-20 15:26 ` Vivek Goyal
2017-07-20 15:59 ` Ross Zwisler
2017-07-20 15:59 ` Ross Zwisler
2017-07-20 15:59 ` Ross Zwisler
2017-07-21 18:02 ` Ross Zwisler
2017-07-21 18:02 ` Ross Zwisler
2017-07-21 18:02 ` Ross Zwisler
2017-06-28 22:01 ` [PATCH v3 2/5] dax: relocate some dax functions Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
2017-06-28 22:01 ` [PATCH v3 3/5] dax: use common 4k zero page for dax mmap reads Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
2017-07-19 15:33 ` Jan Kara
2017-07-19 15:33 ` Jan Kara
[not found] ` <20170719153314.GC15908-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
2017-07-19 16:26 ` Ross Zwisler
2017-07-19 16:26 ` Ross Zwisler
2017-07-19 16:26 ` Ross Zwisler
2017-07-19 16:26 ` Ross Zwisler
[not found] ` <20170719162645.GA26445-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-07-20 10:27 ` Jan Kara
2017-07-20 10:27 ` Jan Kara
2017-07-20 10:27 ` Jan Kara
2017-07-20 10:27 ` Jan Kara
[not found] ` <20170720102723.GB17689-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
2017-07-20 14:28 ` Ross Zwisler
2017-07-20 14:28 ` Ross Zwisler
2017-07-20 14:28 ` Ross Zwisler
2017-07-20 14:28 ` Ross Zwisler
2017-06-28 22:01 ` [PATCH v3 4/5] dax: remove DAX code from page_cache_tree_insert() Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
2017-06-28 22:01 ` [PATCH v3 5/5] dax: move all DAX radix tree defs to fs/dax.c Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
2017-06-28 22:01 ` Ross Zwisler
2017-06-30 19:05 ` Ross Zwisler [this message]
2017-06-30 19:05 ` [PATCH v3 0/5] DAX common 4k zero page Ross Zwisler
2017-06-30 19:05 ` Ross Zwisler
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=20170630190556.GB27371@linux.intel.com \
--to=ross.zwisler@linux.intel.com \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=darrick.wong@oracle.com \
--cc=dave.hansen@intel.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=linux-doc@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mawilcox@microsoft.com \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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.