[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170630190556.GB27371@linux.intel.com>
Date: Fri, 30 Jun 2017 13:05:56 -0600
From: Ross Zwisler <ross.zwisler@...ux.intel.com>
To: Ross Zwisler <ross.zwisler@...ux.intel.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
"Darrick J. Wong" <darrick.wong@...cle.com>,
Theodore Ts'o <tytso@....edu>,
Alexander Viro <viro@...iv.linux.org.uk>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Christoph Hellwig <hch@....de>,
Dan Williams <dan.j.williams@...el.com>,
Dave Hansen <dave.hansen@...el.com>,
Ingo Molnar <mingo@...hat.com>, Jan Kara <jack@...e.cz>,
Jonathan Corbet <corbet@....net>,
Matthew Wilcox <mawilcox@...rosoft.com>,
Steven Rostedt <rostedt@...dmis.org>,
linux-doc@...r.kernel.org, linux-ext4@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
linux-nvdimm@...ts.01.org, linux-xfs@...r.kernel.org
Subject: Re: [PATCH v3 0/5] DAX common 4k zero page
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.
Powered by blists - more mailing lists