| Message ID | 147392247875.9873.4205533916442000884.stgit@dwillia2-desk3.amr.corp.intel.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Wed, Sep 14, 2016 at 11:54:38PM -0700, Dan Williams wrote: > The DAX property, page cache bypass, of a VMA is only detectable via the > vma_is_dax() helper to check the S_DAX inode flag. However, this is > only available internal to the kernel and is a property that userspace > applications would like to interrogate. They have absolutely no business knowing such an implementation detail.
On Thu, Sep 15, 2016 at 1:26 AM, Christoph Hellwig <hch@lst.de> wrote: > On Wed, Sep 14, 2016 at 11:54:38PM -0700, Dan Williams wrote: >> The DAX property, page cache bypass, of a VMA is only detectable via the >> vma_is_dax() helper to check the S_DAX inode flag. However, this is >> only available internal to the kernel and is a property that userspace >> applications would like to interrogate. > > They have absolutely no business knowing such an implementation detail. Hasn't that train already left the station with FS_XFLAG_DAX? The other problem with hiding the DAX property is that it turns out to not be a transparent acceleration feature. See xfs/086 xfs/088 xfs/089 xfs/091 which fail with DAX and, as far as I understand, it is due to the fact that DAX disallows delayed allocation behavior. If behavior changes I think we should indicate that to userspace and VM_DAX is certainly more useful to userspace than some of the other vm internals we already export in those flags.
On Thu, Sep 15, 2016 at 10:01:03AM -0700, Dan Williams wrote: > On Thu, Sep 15, 2016 at 1:26 AM, Christoph Hellwig <hch@lst.de> wrote: > > On Wed, Sep 14, 2016 at 11:54:38PM -0700, Dan Williams wrote: > >> The DAX property, page cache bypass, of a VMA is only detectable via the > >> vma_is_dax() helper to check the S_DAX inode flag. However, this is > >> only available internal to the kernel and is a property that userspace > >> applications would like to interrogate. > > > > They have absolutely no business knowing such an implementation detail. > > Hasn't that train already left the station with FS_XFLAG_DAX? Seeing as FS_IOC_FSGETXATTR is a "generic" ioctl now, why not just implement it for all the DAX fses and block devices? Aside from xflags, the other fields are probably all zero for non-xfs (aside from project quota id I guess). (Yeah, sort of awkward, I know...) --D > The other problem with hiding the DAX property is that it turns out to > not be a transparent acceleration feature. See xfs/086 xfs/088 > xfs/089 xfs/091 which fail with DAX and, as far as I understand, it is > due to the fact that DAX disallows delayed allocation behavior. > > If behavior changes I think we should indicate that to userspace and > VM_DAX is certainly more useful to userspace than some of the other vm > internals we already export in those flags. > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs
On Thu, Sep 15, 2016 at 10:09 AM, Darrick J. Wong <darrick.wong@oracle.com> wrote: > On Thu, Sep 15, 2016 at 10:01:03AM -0700, Dan Williams wrote: >> On Thu, Sep 15, 2016 at 1:26 AM, Christoph Hellwig <hch@lst.de> wrote: >> > On Wed, Sep 14, 2016 at 11:54:38PM -0700, Dan Williams wrote: >> >> The DAX property, page cache bypass, of a VMA is only detectable via the >> >> vma_is_dax() helper to check the S_DAX inode flag. However, this is >> >> only available internal to the kernel and is a property that userspace >> >> applications would like to interrogate. >> > >> > They have absolutely no business knowing such an implementation detail. >> >> Hasn't that train already left the station with FS_XFLAG_DAX? > > Seeing as FS_IOC_FSGETXATTR is a "generic" ioctl now, why not just > implement it for all the DAX fses and block devices? Aside from xflags, > the other fields are probably all zero for non-xfs (aside from project > quota id I guess). > > (Yeah, sort of awkward, I know...) It would solve the problem at hand, I'll take a look.
diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c index 88fad2519907..1cb4117870bd 100644 --- a/drivers/dax/dax.c +++ b/drivers/dax/dax.c @@ -528,7 +528,7 @@ static int dax_dev_mmap(struct file *filp, struct vm_area_struct *vma) kref_get(&dax_dev->kref); vma->vm_ops = &dax_dev_vm_ops; - vma->vm_flags |= VM_MIXEDMAP | VM_HUGEPAGE | VM_SYNC; + vma->vm_flags |= VM_MIXEDMAP | VM_HUGEPAGE | VM_SYNC | VM_DAX; return 0; } diff --git a/fs/Kconfig b/fs/Kconfig index 2bc7ad775842..6d9afe4c1710 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -38,6 +38,7 @@ config FS_DAX bool "Direct Access (DAX) support" depends on MMU depends on !(ARM || MIPS || SPARC) + select ARCH_USES_HIGH_VMA_FLAGS if 64BIT help Direct Access (DAX) can be used on memory-backed block devices. If the block device supports DAX and the filesystem supports DAX, diff --git a/fs/ext2/file.c b/fs/ext2/file.c index 5efeefe17abb..b9c829cf427c 100644 --- a/fs/ext2/file.c +++ b/fs/ext2/file.c @@ -118,7 +118,7 @@ static int ext2_file_mmap(struct file *file, struct vm_area_struct *vma) file_accessed(file); vma->vm_ops = &ext2_dax_vm_ops; - vma->vm_flags |= VM_MIXEDMAP | VM_HUGEPAGE; + vma->vm_flags |= VM_MIXEDMAP | VM_HUGEPAGE | VM_DAX; return 0; } #else diff --git a/fs/ext4/file.c b/fs/ext4/file.c index 261ac3734c58..7a777f1bbde3 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -312,7 +312,7 @@ static int ext4_file_mmap(struct file *file, struct vm_area_struct *vma) file_accessed(file); if (IS_DAX(file_inode(file))) { vma->vm_ops = &ext4_dax_vm_ops; - vma->vm_flags |= VM_MIXEDMAP | VM_HUGEPAGE; + vma->vm_flags |= VM_MIXEDMAP | VM_HUGEPAGE | VM_DAX; } else { vma->vm_ops = &ext4_file_vm_ops; } diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 03a65ac7f222..b9b9dc059e19 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -677,6 +677,7 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma) #endif #ifdef CONFIG_ARCH_USES_HIGH_VMA_FLAGS [ilog2(VM_SYNC)] = "sn", + [ilog2(VM_DAX)] = "dx", #endif }; size_t i; diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c index e612a0233710..80ed83405683 100644 --- a/fs/xfs/xfs_file.c +++ b/fs/xfs/xfs_file.c @@ -1644,7 +1644,7 @@ xfs_file_mmap( file_accessed(filp); vma->vm_ops = &xfs_file_vm_ops; if (IS_DAX(file_inode(filp))) - vma->vm_flags |= VM_MIXEDMAP | VM_HUGEPAGE; + vma->vm_flags |= VM_MIXEDMAP | VM_HUGEPAGE | VM_DAX; return 0; } diff --git a/include/linux/mm.h b/include/linux/mm.h index f3f6df6bb498..5930402596c0 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -204,11 +204,13 @@ extern unsigned int kobjsize(const void *objp); #define VM_HIGH_ARCH_BIT_2 34 #define VM_HIGH_ARCH_BIT_3 35 #define VM_HIGH_ARCH_BIT_4 36 +#define VM_HIGH_ARCH_BIT_5 37 #define VM_HIGH_ARCH_0 BIT(VM_HIGH_ARCH_BIT_0) #define VM_HIGH_ARCH_1 BIT(VM_HIGH_ARCH_BIT_1) #define VM_HIGH_ARCH_2 BIT(VM_HIGH_ARCH_BIT_2) #define VM_HIGH_ARCH_3 BIT(VM_HIGH_ARCH_BIT_3) #define VM_HIGH_ARCH_4 BIT(VM_HIGH_ARCH_BIT_4) +#define VM_HIGH_ARCH_5 BIT(VM_HIGH_ARCH_BIT_5) #endif /* CONFIG_ARCH_USES_HIGH_VMA_FLAGS */ #if defined(CONFIG_X86) @@ -243,8 +245,16 @@ extern unsigned int kobjsize(const void *objp); * synced before fault handler returns to userspace */ #define VM_SYNC VM_HIGH_ARCH_4 +/* + * Mapping is not indirected through the page-cache, accesses hit memory + * media directly*. + * + * (*) a fileystem may map the zero-page into holes of a file. + */ +#define VM_DAX VM_HIGH_ARCH_5 #else #define VM_SYNC 0 +#define VM_DAX 0 #endif #ifndef VM_GROWSUP
The DAX property, page cache bypass, of a VMA is only detectable via the vma_is_dax() helper to check the S_DAX inode flag. However, this is only available internal to the kernel and is a property that userspace applications would like to interrogate. Yes, this new VM_DAX flag is only available on 64-bit, but the expectation is that the capacities of persistent memory devices are too large for 32-bit platforms. While there is usage of DAX on 32-bit, that usage is primarily driven by DAX's replacement of XIP. XIP is a memory saving technique for embedded devices to execute out of DAX, but in that usage the application does not need to discern if page cache is present or not. Signed-off-by: Dan Williams <dan.j.williams@intel.com> --- drivers/dax/dax.c | 2 +- fs/Kconfig | 1 + fs/ext2/file.c | 2 +- fs/ext4/file.c | 2 +- fs/proc/task_mmu.c | 1 + fs/xfs/xfs_file.c | 2 +- include/linux/mm.h | 10 ++++++++++ 7 files changed, 16 insertions(+), 4 deletions(-)