DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This series allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled.
This series restores DAX PMD functionality back to what it was before it
was disabled. There is still a known issue between DAX PMDs and hole
punch, which I am currently working on and which I plan to address with a
separate series.
Ross Zwisler (7):
ext2: tell DAX the size of allocation holes
ext4: tell DAX the size of allocation holes
dax: remove buffer_size_valid()
dax: rename 'ret' to 'entry' in grab_mapping_entry
dax: lock based on slot instead of [mapping, index]
dax: re-enable DAX PMD support
dax: remove "depends on BROKEN" from FS_DAX_PMD
fs/Kconfig | 1 -
fs/dax.c | 301 ++++++++++++++++++++++++++--------------------------
fs/ext2/inode.c | 6 ++
fs/ext4/inode.c | 3 +
include/linux/dax.h | 30 +++++-
mm/filemap.c | 7 +-
6 files changed, 191 insertions(+), 157 deletions(-)
--
2.9.0
On Mon, Aug 15, 2016 at 12:09 PM, Ross Zwisler
<ross.zwisler-VuQAYsv1563Yd54FQh9/[email protected]> wrote:
> DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
> locking. This series allows DAX PMDs to participate in the DAX radix tree
> based locking scheme so that they can be re-enabled.
Looks good to me.
> This series restores DAX PMD functionality back to what it was before it
> was disabled. There is still a known issue between DAX PMDs and hole
> punch, which I am currently working on and which I plan to address with a
> separate series.
Perhaps we should hold off on applying patch 6 and 7 until after the
hole-punch fix is ready?
On Mon, Aug 15, 2016 at 01:21:47PM -0700, Dan Williams wrote:
> On Mon, Aug 15, 2016 at 12:09 PM, Ross Zwisler
> <[email protected]> wrote:
> > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
> > locking. This series allows DAX PMDs to participate in the DAX radix tree
> > based locking scheme so that they can be re-enabled.
>
> Looks good to me.
>
> > This series restores DAX PMD functionality back to what it was before it
> > was disabled. There is still a known issue between DAX PMDs and hole
> > punch, which I am currently working on and which I plan to address with a
> > separate series.
>
> Perhaps we should hold off on applying patch 6 and 7 until after the
> hole-punch fix is ready?
Sure, I'm cool with holding off on patch 7 (the Kconfig change) until after
the hole punch fix is ready.
I don't see a reason to hold off on patch 6, though? It stands on it's own,
implements the correct locking, and doesn't break anything.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
On Mon, Aug 15, 2016 at 2:11 PM, Ross Zwisler
<[email protected]> wrote:
> On Mon, Aug 15, 2016 at 01:21:47PM -0700, Dan Williams wrote:
>> On Mon, Aug 15, 2016 at 12:09 PM, Ross Zwisler
>> <[email protected]> wrote:
>> > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
>> > locking. This series allows DAX PMDs to participate in the DAX radix tree
>> > based locking scheme so that they can be re-enabled.
>>
>> Looks good to me.
>>
>> > This series restores DAX PMD functionality back to what it was before it
>> > was disabled. There is still a known issue between DAX PMDs and hole
>> > punch, which I am currently working on and which I plan to address with a
>> > separate series.
>>
>> Perhaps we should hold off on applying patch 6 and 7 until after the
>> hole-punch fix is ready?
>
> Sure, I'm cool with holding off on patch 7 (the Kconfig change) until after
> the hole punch fix is ready.
>
> I don't see a reason to hold off on patch 6, though? It stands on it's own,
> implements the correct locking, and doesn't break anything.
Whoops, I just meant 7.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
On Mon, Aug 15, 2016 at 02:14:14PM -0700, Dan Williams wrote:
> On Mon, Aug 15, 2016 at 2:11 PM, Ross Zwisler
> <ross.zwisler-VuQAYsv1563Yd54FQh9/[email protected]> wrote:
> > On Mon, Aug 15, 2016 at 01:21:47PM -0700, Dan Williams wrote:
> >> On Mon, Aug 15, 2016 at 12:09 PM, Ross Zwisler
> >> <ross.zwisler-VuQAYsv1563Yd54FQh9/[email protected]> wrote:
> >> > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
> >> > locking. This series allows DAX PMDs to participate in the DAX radix tree
> >> > based locking scheme so that they can be re-enabled.
> >>
> >> Looks good to me.
> >>
> >> > This series restores DAX PMD functionality back to what it was before it
> >> > was disabled. There is still a known issue between DAX PMDs and hole
> >> > punch, which I am currently working on and which I plan to address with a
> >> > separate series.
> >>
> >> Perhaps we should hold off on applying patch 6 and 7 until after the
> >> hole-punch fix is ready?
> >
> > Sure, I'm cool with holding off on patch 7 (the Kconfig change) until after
> > the hole punch fix is ready.
> >
> > I don't see a reason to hold off on patch 6, though? It stands on it's own,
> > implements the correct locking, and doesn't break anything.
>
> Whoops, I just meant 7.
Well, it looks like the hole punch case is much improved since I tested it
last! :) I used to be able to generate a few different kernel BUGs when hole
punching DAX PMDs, but those have apparently been fixed in the mm layer since
I was last testing, which admittedly was quite a long time ago (February?).
The only issue I was able to find with DAX PMD hole punching was that ext4
wasn't properly doing a writeback before the hole was unmapped and the radix
tree entries were removed. This issue applies equally to the 4k case, so I've
submitted a bug fix for v4.8:
https://lists.01.org/pipermail/linux-nvdimm/2016-August/006621.html
With that applied, I don't know of any more issues related to DAX PMDs and
hole punch. I've tested ext4 and XFS (ext2 doesn't support hole punch), and
they both properly do a writeback of all affected PMDs, fully unmap all
affected PMDs, and remove the radix tree entries. I've tested that new page
faults for addresses previously covered by the old PMDs generate new page
faults, and 4k pages are now faulted in because the block allocator no longer
has 2MiB contiguous allocations.
One question (probably for Jan): should the above ext4 fix be marked for
stable?
Thanks,
- Ross
On Wed 17-08-16 10:21:24, Ross Zwisler wrote:
> On Mon, Aug 15, 2016 at 02:14:14PM -0700, Dan Williams wrote:
> > On Mon, Aug 15, 2016 at 2:11 PM, Ross Zwisler
> > <ross.zwisler-VuQAYsv1563Yd54FQh9/[email protected]> wrote:
> > > On Mon, Aug 15, 2016 at 01:21:47PM -0700, Dan Williams wrote:
> > >> On Mon, Aug 15, 2016 at 12:09 PM, Ross Zwisler
> > >> <ross.zwisler-VuQAYsv1563Yd54FQh9/[email protected]> wrote:
> > >> > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
> > >> > locking. This series allows DAX PMDs to participate in the DAX radix tree
> > >> > based locking scheme so that they can be re-enabled.
> > >>
> > >> Looks good to me.
> > >>
> > >> > This series restores DAX PMD functionality back to what it was before it
> > >> > was disabled. There is still a known issue between DAX PMDs and hole
> > >> > punch, which I am currently working on and which I plan to address with a
> > >> > separate series.
> > >>
> > >> Perhaps we should hold off on applying patch 6 and 7 until after the
> > >> hole-punch fix is ready?
> > >
> > > Sure, I'm cool with holding off on patch 7 (the Kconfig change) until after
> > > the hole punch fix is ready.
> > >
> > > I don't see a reason to hold off on patch 6, though? It stands on it's own,
> > > implements the correct locking, and doesn't break anything.
> >
> > Whoops, I just meant 7.
>
> Well, it looks like the hole punch case is much improved since I tested it
> last! :) I used to be able to generate a few different kernel BUGs when hole
> punching DAX PMDs, but those have apparently been fixed in the mm layer since
> I was last testing, which admittedly was quite a long time ago (February?).
>
> The only issue I was able to find with DAX PMD hole punching was that ext4
> wasn't properly doing a writeback before the hole was unmapped and the radix
> tree entries were removed. This issue applies equally to the 4k case, so I've
> submitted a bug fix for v4.8:
>
> https://lists.01.org/pipermail/linux-nvdimm/2016-August/006621.html
>
> With that applied, I don't know of any more issues related to DAX PMDs and
> hole punch. I've tested ext4 and XFS (ext2 doesn't support hole punch), and
> they both properly do a writeback of all affected PMDs, fully unmap all
> affected PMDs, and remove the radix tree entries. I've tested that new page
> faults for addresses previously covered by the old PMDs generate new page
> faults, and 4k pages are now faulted in because the block allocator no longer
> has 2MiB contiguous allocations.
>
> One question (probably for Jan): should the above ext4 fix be marked for
> stable?
Yes, probably it should be.
Honza
--
Jan Kara <jack-IBi9RG/[email protected]>
SUSE Labs, CR