Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1500509
| From | Ross Zwisler <ross.zwisler@linux.intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v6 15/17] dax: add struct iomap based DAX PMD support |
| Date | 2016-10-13 21:30 +0200 |
| Message-ID | <srTRw-7Mi-13@gated-at.bofh.it> (permalink) |
| References | <srAFb-2y2-3@gated-at.bofh.it> <srAFb-2y2-1@gated-at.bofh.it> <srQAh-5qL-17@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, Oct 13, 2016 at 05:42:24PM +0200, Jan Kara wrote: > On Wed 12-10-16 16:50:20, Ross Zwisler wrote: > > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based > > locking. This patch allows DAX PMDs to participate in the DAX radix tree > > based locking scheme so that they can be re-enabled using the new struct > > iomap based fault handlers. > > > > There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX > > mappings that have an associated block allocation, and 4k DAX empty > > entries. The empty entries exist to provide locking for the duration of a > > given page fault. > > > > This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP) > > entries, PMD DAX entries that have associated block allocations, and 2 MiB > > DAX empty entries. > > > > Unlike the 4k case where we insert a struct page* into the radix tree for > > 4k zero pages, for HZP we insert a DAX exceptional entry with the new > > RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in > > every 2MiB hole mapping, and it doesn't make sense to have that same struct > > page* with multiple entries in multiple trees. This would cause contention > > on the single page lock for the one Huge Zero Page, and it would break the > > page->index and page->mapping associations that are assumed to be valid in > > many other places in the kernel. > > > > One difficult use case is when one thread is trying to use 4k entries in > > radix tree for a given offset, and another thread is using 2 MiB entries > > for that same offset. The current code handles this by making the 2 MiB > > user fall back to 4k entries for most cases. This was done because it is > > the simplest solution, and because the use of 2MiB pages is already > > opportunistic. > > > > If we were to try to upgrade from 4k pages to 2MiB pages for a given range, > > we run into the problem of how we lock out 4k page faults for the entire > > 2MiB range while we clean out the radix tree so we can insert the 2MiB > > entry. We can solve this problem if we need to, but I think that the cases > > where both 2MiB entries and 4K entries are being used for the same range > > will be rare enough and the gain small enough that it probably won't be > > worth the complexity. > > > > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> > > Just one small bug below. Feel free to add: > > Reviewed-by: Jan Kara <jack@suse.cz> > > after fixing that. Fixed, thank you for the catch and the review!
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH v6 15/17] dax: add struct iomap based DAX PMD support Jan Kara <jack@suse.cz> - 2016-10-13 18:00 +0200
Re: [PATCH v6 15/17] dax: add struct iomap based DAX PMD support Ross Zwisler <ross.zwisler@linux.intel.com> - 2016-10-13 21:30 +0200
[PATCH v7 15/17] dax: add struct iomap based DAX PMD support Ross Zwisler <ross.zwisler@linux.intel.com> - 2016-10-13 21:30 +0200
Re: [PATCH v7 15/17] dax: add struct iomap based DAX PMD support "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> - 2016-10-17 08:40 +0200
Re: [PATCH v7 15/17] dax: add struct iomap based DAX PMD support Ross Zwisler <ross.zwisler@linux.intel.com> - 2016-10-17 17:00 +0200
csiph-web