From: Ira Weiny <ira.weiny@intel.com> To: Vivek Goyal <vgoyal@redhat.com> Cc: Michal Hocko <mhocko@suse.com>, Jan Kara <jack@suse.cz>, linux-nvdimm@lists.01.org, linux-rdma@vger.kernel.org, John Hubbard <jhubbard@nvidia.com>, Dave Chinner <david@fromorbit.com>, linux-kernel@vger.kernel.org, Matthew Wilcox <willy@infradead.org>, linux-xfs@vger.kernel.org, Jason Gunthorpe <jgg@ziepe.ca>, linux-fsdevel@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>, Andrew Morton <akpm@linux-foundation.org>, linux-ext4@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH v2 06/19] fs/ext4: Teach dax_layout_busy_page() to operate on a sub-range Date: Thu, 29 Aug 2019 11:52:15 -0700 [thread overview] Message-ID: <20190829185215.GC18249@iweiny-DESK2.sc.intel.com> (raw) In-Reply-To: <20190823151826.GB11009@redhat.com> On Fri, Aug 23, 2019 at 11:18:26AM -0400, Vivek Goyal wrote: > On Fri, Aug 09, 2019 at 03:58:20PM -0700, ira.weiny@intel.com wrote: > > From: Ira Weiny <ira.weiny@intel.com> > > > > Callers of dax_layout_busy_page() are only rarely operating on the > > entire file of concern. > > > > Teach dax_layout_busy_page() to operate on a sub-range of the > > address_space provided. Specifying 0 - ULONG_MAX however, will continue > > to operate on the "entire file" and XFS is split out to a separate patch > > by this method. > > > > This could potentially speed up dax_layout_busy_page() as well. > > I need this functionality as well for virtio_fs and posted a patch for > this. > > https://lkml.org/lkml/2019/8/21/825 > > Given this is an optimization which existing users can benefit from already, > this patch could probably be pushed upstream independently. I'm ok with that. However, this patch does not apply cleanly to head as I had some other additions to dax.h. > > > > > Signed-off-by: Ira Weiny <ira.weiny@intel.com> > > > > --- > > Changes from RFC v1 > > Fix 0-day build errors > > > > fs/dax.c | 15 +++++++++++---- > > fs/ext4/ext4.h | 2 +- > > fs/ext4/extents.c | 6 +++--- > > fs/ext4/inode.c | 19 ++++++++++++------- > > fs/xfs/xfs_file.c | 3 ++- > > include/linux/dax.h | 6 ++++-- > > 6 files changed, 33 insertions(+), 18 deletions(-) > > > > diff --git a/fs/dax.c b/fs/dax.c > > index a14ec32255d8..3ad19c384454 100644 > > --- a/fs/dax.c > > +++ b/fs/dax.c > > @@ -573,8 +573,11 @@ bool dax_mapping_is_dax(struct address_space *mapping) > > EXPORT_SYMBOL_GPL(dax_mapping_is_dax); > > > > /** > > - * dax_layout_busy_page - find first pinned page in @mapping > > + * dax_layout_busy_page - find first pinned page in @mapping within > > + * the range @off - @off + @len > > * @mapping: address space to scan for a page with ref count > 1 > > + * @off: offset to start at > > + * @len: length to scan through > > * > > * DAX requires ZONE_DEVICE mapped pages. These pages are never > > * 'onlined' to the page allocator so they are considered idle when > > @@ -587,9 +590,13 @@ EXPORT_SYMBOL_GPL(dax_mapping_is_dax); > > * to be able to run unmap_mapping_range() and subsequently not race > > * mapping_mapped() becoming true. > > */ > > -struct page *dax_layout_busy_page(struct address_space *mapping) > > +struct page *dax_layout_busy_page(struct address_space *mapping, > > + loff_t off, loff_t len) > > { > > - XA_STATE(xas, &mapping->i_pages, 0); > > + unsigned long start_idx = off >> PAGE_SHIFT; > > + unsigned long end_idx = (len == ULONG_MAX) ? ULONG_MAX > > + : start_idx + (len >> PAGE_SHIFT); > > + XA_STATE(xas, &mapping->i_pages, start_idx); > > void *entry; > > unsigned int scanned = 0; > > struct page *page = NULL; > > @@ -612,7 +619,7 @@ struct page *dax_layout_busy_page(struct address_space *mapping) > > unmap_mapping_range(mapping, 0, 0, 1); > > Should we unmap only those pages which fall in the range specified by caller. > Unmapping whole file seems to be less efficient. Seems reasonable to me. I was focused on getting pages which were busy not necessarily on what got unmapped. So I did not consider this. Thanks for the suggestion. However, I don't understand the math you do for length? Is this comment/code correct? + /* length is being calculated from lstart and not start. + * This is due to behavior of unmap_mapping_range(). If + * start is say 4094 and end is on 4093 then want to + * unamp two pages, idx 0 and 1. But unmap_mapping_range() + * will unmap only page at idx 0. If we calculate len + * from the rounded down start, this problem should not + * happen. + */ + len = end - lstart + 1; How can end (4093) be < start (4094)? Is that valid? And why would a start of 4094 unmap idx 0? Ira _______________________________________________ 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: Ira Weiny <ira.weiny@intel.com> To: Vivek Goyal <vgoyal@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@suse.com>, Jan Kara <jack@suse.cz>, linux-nvdimm@lists.01.org, linux-rdma@vger.kernel.org, John Hubbard <jhubbard@nvidia.com>, Dave Chinner <david@fromorbit.com>, linux-kernel@vger.kernel.org, Matthew Wilcox <willy@infradead.org>, linux-xfs@vger.kernel.org, Jason Gunthorpe <jgg@ziepe.ca>, linux-fsdevel@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>, linux-ext4@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH v2 06/19] fs/ext4: Teach dax_layout_busy_page() to operate on a sub-range Date: Thu, 29 Aug 2019 11:52:15 -0700 [thread overview] Message-ID: <20190829185215.GC18249@iweiny-DESK2.sc.intel.com> (raw) In-Reply-To: <20190823151826.GB11009@redhat.com> On Fri, Aug 23, 2019 at 11:18:26AM -0400, Vivek Goyal wrote: > On Fri, Aug 09, 2019 at 03:58:20PM -0700, ira.weiny@intel.com wrote: > > From: Ira Weiny <ira.weiny@intel.com> > > > > Callers of dax_layout_busy_page() are only rarely operating on the > > entire file of concern. > > > > Teach dax_layout_busy_page() to operate on a sub-range of the > > address_space provided. Specifying 0 - ULONG_MAX however, will continue > > to operate on the "entire file" and XFS is split out to a separate patch > > by this method. > > > > This could potentially speed up dax_layout_busy_page() as well. > > I need this functionality as well for virtio_fs and posted a patch for > this. > > https://lkml.org/lkml/2019/8/21/825 > > Given this is an optimization which existing users can benefit from already, > this patch could probably be pushed upstream independently. I'm ok with that. However, this patch does not apply cleanly to head as I had some other additions to dax.h. > > > > > Signed-off-by: Ira Weiny <ira.weiny@intel.com> > > > > --- > > Changes from RFC v1 > > Fix 0-day build errors > > > > fs/dax.c | 15 +++++++++++---- > > fs/ext4/ext4.h | 2 +- > > fs/ext4/extents.c | 6 +++--- > > fs/ext4/inode.c | 19 ++++++++++++------- > > fs/xfs/xfs_file.c | 3 ++- > > include/linux/dax.h | 6 ++++-- > > 6 files changed, 33 insertions(+), 18 deletions(-) > > > > diff --git a/fs/dax.c b/fs/dax.c > > index a14ec32255d8..3ad19c384454 100644 > > --- a/fs/dax.c > > +++ b/fs/dax.c > > @@ -573,8 +573,11 @@ bool dax_mapping_is_dax(struct address_space *mapping) > > EXPORT_SYMBOL_GPL(dax_mapping_is_dax); > > > > /** > > - * dax_layout_busy_page - find first pinned page in @mapping > > + * dax_layout_busy_page - find first pinned page in @mapping within > > + * the range @off - @off + @len > > * @mapping: address space to scan for a page with ref count > 1 > > + * @off: offset to start at > > + * @len: length to scan through > > * > > * DAX requires ZONE_DEVICE mapped pages. These pages are never > > * 'onlined' to the page allocator so they are considered idle when > > @@ -587,9 +590,13 @@ EXPORT_SYMBOL_GPL(dax_mapping_is_dax); > > * to be able to run unmap_mapping_range() and subsequently not race > > * mapping_mapped() becoming true. > > */ > > -struct page *dax_layout_busy_page(struct address_space *mapping) > > +struct page *dax_layout_busy_page(struct address_space *mapping, > > + loff_t off, loff_t len) > > { > > - XA_STATE(xas, &mapping->i_pages, 0); > > + unsigned long start_idx = off >> PAGE_SHIFT; > > + unsigned long end_idx = (len == ULONG_MAX) ? ULONG_MAX > > + : start_idx + (len >> PAGE_SHIFT); > > + XA_STATE(xas, &mapping->i_pages, start_idx); > > void *entry; > > unsigned int scanned = 0; > > struct page *page = NULL; > > @@ -612,7 +619,7 @@ struct page *dax_layout_busy_page(struct address_space *mapping) > > unmap_mapping_range(mapping, 0, 0, 1); > > Should we unmap only those pages which fall in the range specified by caller. > Unmapping whole file seems to be less efficient. Seems reasonable to me. I was focused on getting pages which were busy not necessarily on what got unmapped. So I did not consider this. Thanks for the suggestion. However, I don't understand the math you do for length? Is this comment/code correct? + /* length is being calculated from lstart and not start. + * This is due to behavior of unmap_mapping_range(). If + * start is say 4094 and end is on 4093 then want to + * unamp two pages, idx 0 and 1. But unmap_mapping_range() + * will unmap only page at idx 0. If we calculate len + * from the rounded down start, this problem should not + * happen. + */ + len = end - lstart + 1; How can end (4093) be < start (4094)? Is that valid? And why would a start of 4094 unmap idx 0? Ira
next prev parent reply other threads:[~2019-08-29 18:54 UTC|newest] Thread overview: 201+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-09 22:58 [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 22:58 ` [RFC PATCH v2 01/19] fs/locks: Export F_LAYOUT lease to user space ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 23:52 ` Dave Chinner 2019-08-09 23:52 ` Dave Chinner 2019-08-12 17:36 ` Ira Weiny 2019-08-12 17:36 ` Ira Weiny 2019-08-14 8:05 ` Dave Chinner 2019-08-14 8:05 ` Dave Chinner 2019-08-14 11:21 ` Jeff Layton 2019-08-14 11:21 ` Jeff Layton 2019-08-14 11:21 ` Jeff Layton 2019-08-14 11:38 ` Dave Chinner 2019-08-14 11:38 ` Dave Chinner 2019-08-09 22:58 ` [RFC PATCH v2 02/19] fs/locks: Add Exclusive flag to user Layout lease ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-14 14:15 ` Jeff Layton 2019-08-14 14:15 ` Jeff Layton 2019-08-14 14:15 ` Jeff Layton 2019-08-14 21:56 ` Dave Chinner 2019-08-26 10:41 ` Jeff Layton 2019-08-26 10:41 ` Jeff Layton 2019-08-26 10:41 ` Jeff Layton 2019-08-29 23:34 ` Ira Weiny 2019-08-29 23:34 ` Ira Weiny 2019-09-04 12:52 ` Jeff Layton 2019-09-04 12:52 ` Jeff Layton 2019-09-04 23:12 ` John Hubbard 2019-09-04 23:12 ` John Hubbard 2019-08-09 22:58 ` [RFC PATCH v2 03/19] mm/gup: Pass flags down to __gup_device_huge* calls ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 22:58 ` [RFC PATCH v2 04/19] mm/gup: Ensure F_LAYOUT lease is held prior to GUP'ing pages ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 22:58 ` [RFC PATCH v2 05/19] fs/ext4: Teach ext4 to break layout leases ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 22:58 ` [RFC PATCH v2 06/19] fs/ext4: Teach dax_layout_busy_page() to operate on a sub-range ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-23 15:18 ` Vivek Goyal 2019-08-23 15:18 ` Vivek Goyal 2019-08-29 18:52 ` Ira Weiny [this message] 2019-08-29 18:52 ` Ira Weiny 2019-08-09 22:58 ` [RFC PATCH v2 07/19] fs/xfs: Teach xfs to use new dax_layout_busy_page() ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 23:30 ` Dave Chinner 2019-08-09 23:30 ` Dave Chinner 2019-08-12 18:05 ` Ira Weiny 2019-08-12 18:05 ` Ira Weiny 2019-08-14 8:04 ` Dave Chinner 2019-08-09 22:58 ` [RFC PATCH v2 08/19] fs/xfs: Fail truncate if page lease can't be broken ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 23:22 ` Dave Chinner 2019-08-09 23:22 ` Dave Chinner 2019-08-12 18:08 ` Ira Weiny 2019-08-09 22:58 ` [RFC PATCH v2 09/19] mm/gup: Introduce vaddr_pin structure ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-10 0:06 ` John Hubbard 2019-08-10 0:06 ` John Hubbard 2019-08-10 0:06 ` John Hubbard 2019-08-09 22:58 ` [RFC PATCH v2 10/19] mm/gup: Pass a NULL vaddr_pin through GUP fast ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-10 0:06 ` John Hubbard 2019-08-10 0:06 ` John Hubbard 2019-08-10 0:06 ` John Hubbard 2019-08-09 22:58 ` [RFC PATCH v2 11/19] mm/gup: Pass follow_page_context further down the call stack ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-10 0:18 ` John Hubbard 2019-08-10 0:18 ` John Hubbard 2019-08-10 0:18 ` John Hubbard 2019-08-12 19:01 ` Ira Weiny 2019-08-12 19:01 ` Ira Weiny 2019-08-09 22:58 ` [RFC PATCH v2 12/19] mm/gup: Prep put_user_pages() to take an vaddr_pin struct ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-10 0:30 ` John Hubbard 2019-08-10 0:30 ` John Hubbard 2019-08-10 0:30 ` John Hubbard 2019-08-12 20:46 ` Ira Weiny 2019-08-09 22:58 ` [RFC PATCH v2 13/19] {mm,file}: Add file_pins objects ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 22:58 ` [RFC PATCH v2 14/19] fs/locks: Associate file pins while performing GUP ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 22:58 ` [RFC PATCH v2 15/19] mm/gup: Introduce vaddr_pin_pages() ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-10 0:09 ` John Hubbard 2019-08-10 0:09 ` John Hubbard 2019-08-10 0:09 ` John Hubbard 2019-08-12 21:00 ` Ira Weiny 2019-08-12 21:00 ` Ira Weiny 2019-08-12 21:20 ` John Hubbard 2019-08-12 21:20 ` John Hubbard 2019-08-12 21:20 ` John Hubbard 2019-08-11 23:07 ` John Hubbard 2019-08-11 23:07 ` John Hubbard 2019-08-11 23:07 ` John Hubbard 2019-08-12 21:01 ` Ira Weiny 2019-08-12 12:28 ` Jason Gunthorpe 2019-08-12 21:48 ` Ira Weiny 2019-08-12 21:48 ` Ira Weiny 2019-08-13 11:47 ` Jason Gunthorpe 2019-08-13 17:46 ` Ira Weiny 2019-08-13 17:46 ` Ira Weiny 2019-08-13 17:56 ` John Hubbard 2019-08-13 17:56 ` John Hubbard 2019-08-13 17:56 ` John Hubbard 2019-08-09 22:58 ` [RFC PATCH v2 16/19] RDMA/uverbs: Add back pointer to system file object ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-12 13:00 ` Jason Gunthorpe 2019-08-12 17:28 ` Ira Weiny 2019-08-12 17:56 ` Jason Gunthorpe 2019-08-12 21:15 ` Ira Weiny 2019-08-12 21:15 ` Ira Weiny 2019-08-13 11:48 ` Jason Gunthorpe 2019-08-13 17:41 ` Ira Weiny 2019-08-13 17:41 ` Ira Weiny 2019-08-13 18:00 ` Jason Gunthorpe 2019-08-13 20:38 ` Ira Weiny 2019-08-13 20:38 ` Ira Weiny 2019-08-14 12:23 ` Jason Gunthorpe 2019-08-14 17:50 ` Ira Weiny 2019-08-14 18:15 ` Jason Gunthorpe 2019-09-04 22:25 ` Ira Weiny 2019-09-11 8:19 ` Jason Gunthorpe 2019-08-09 22:58 ` [RFC PATCH v2 17/19] RDMA/umem: Convert to vaddr_[pin|unpin]* operations ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 22:58 ` [RFC PATCH v2 18/19] {mm,procfs}: Add display file_pins proc ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 22:58 ` [RFC PATCH v2 19/19] mm/gup: Remove FOLL_LONGTERM DAX exclusion ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-14 10:17 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Jan Kara 2019-08-14 18:08 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-14 18:08 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-08-15 13:05 ` Jan Kara 2019-08-16 19:05 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-16 19:05 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-08-16 23:20 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-16 23:20 ` Ira Weiny 2019-08-19 6:36 ` Jan Kara 2019-08-19 6:36 ` Jan Kara 2019-08-17 2:26 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-17 2:26 ` Dave Chinner 2019-08-19 6:34 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Jan Kara 2019-08-19 6:34 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Jan Kara 2019-08-19 9:24 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-08-19 9:24 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-19 12:38 ` Jason Gunthorpe 2019-08-19 21:53 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-19 21:53 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-08-20 1:12 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-08-20 1:12 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-20 11:55 ` Jason Gunthorpe 2019-08-21 18:02 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-21 18:02 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-08-21 18:13 ` Jason Gunthorpe 2019-08-21 18:22 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) John Hubbard 2019-08-21 18:22 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) John Hubbard 2019-08-21 18:57 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-21 18:57 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-08-21 19:06 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-21 19:06 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-08-21 19:48 ` Jason Gunthorpe 2019-08-21 20:44 ` Ira Weiny 2019-08-21 23:49 ` Jason Gunthorpe 2019-08-23 3:23 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-08-23 3:23 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-23 12:04 ` Jason Gunthorpe 2019-08-24 0:11 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-08-24 0:11 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-24 5:08 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-24 5:08 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-08-26 5:55 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-08-26 5:55 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-29 2:02 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-29 2:02 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-08-29 3:27 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) John Hubbard 2019-08-29 3:27 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) John Hubbard 2019-08-29 16:16 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-29 16:16 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-09-02 22:26 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-09-02 22:26 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-09-04 16:54 ` Ira Weiny 2019-08-25 19:39 ` Jason Gunthorpe 2019-08-24 4:49 ` Ira Weiny 2019-08-24 4:49 ` Ira Weiny 2019-08-25 19:40 ` Jason Gunthorpe 2019-08-23 0:59 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-08-23 0:59 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-23 17:15 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-23 17:15 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-08-24 0:18 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-08-24 0:18 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-20 0:05 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) John Hubbard 2019-08-20 0:05 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) John Hubbard 2019-08-20 1:20 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-08-20 1:20 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-20 3:09 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) John Hubbard 2019-08-20 3:09 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) John Hubbard 2019-08-20 3:36 ` Dave Chinner 2019-08-21 18:43 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) John Hubbard 2019-08-21 18:43 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) John Hubbard 2019-08-21 19:09 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-21 19:09 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny
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=20190829185215.GC18249@iweiny-DESK2.sc.intel.com \ --to=ira.weiny@intel.com \ --cc=akpm@linux-foundation.org \ --cc=david@fromorbit.com \ --cc=jack@suse.cz \ --cc=jgg@ziepe.ca \ --cc=jhubbard@nvidia.com \ --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-rdma@vger.kernel.org \ --cc=linux-xfs@vger.kernel.org \ --cc=mhocko@suse.com \ --cc=tytso@mit.edu \ --cc=vgoyal@redhat.com \ --cc=willy@infradead.org \ /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: linkBe 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.