Re: [Cluster-devel] [PATCH 11/30] iomap: add the new iomap_iter model
On Thu, Aug 19, 2021 at 9:12 PM Christoph Hellwig wrote: > > On Thu, Aug 19, 2021 at 02:25:52PM -0700, Dan Williams wrote: > > Given most of the iomap_iter users don't care about srcmap, i.e. are > > not COW cases, they are leaving srcmap zero initialized. Should the > > IOMAP types be incremented by one so that there is no IOMAP_HOLE > > confusion? In other words, fold something like this? > > A hole really means nothing to read from the source. The existing code > also relies on that. Ok, I've since found iomap_iter_srcmap(). Sorry for the noise.
Re: [Cluster-devel] [PATCH 23/30] fsdax: switch dax_iomap_rw to use iomap_iter
On Sun, Aug 8, 2021 at 11:33 PM Christoph Hellwig wrote: > > Switch the dax_iomap_rw implementation to use iomap_iter. > > Signed-off-by: Christoph Hellwig > --- > fs/dax.c | 49 - > 1 file changed, 24 insertions(+), 25 deletions(-) Looks straightforward, Reviewed-by: Dan Williams
Re: [Cluster-devel] [PATCH 11/30] iomap: add the new iomap_iter model
On Sun, Aug 8, 2021 at 11:23 PM Christoph Hellwig wrote:
>
> The iomap_iter struct provides a convenient way to package up and
> maintain all the arguments to the various mapping and operation
> functions. It is operated on using the iomap_iter() function that
> is called in loop until the whole range has been processed. Compared
> to the existing iomap_apply() function this avoid an indirect call
> for each iteration.
>
> For now iomap_iter() calls back into the existing ->iomap_begin and
> ->iomap_end methods, but in the future this could be further optimized
> to avoid indirect calls entirely.
>
> Based on an earlier patch from Matthew Wilcox .
>
> Signed-off-by: Christoph Hellwig
> ---
> fs/iomap/Makefile | 1 +
> fs/iomap/core.c | 79 +++
> fs/iomap/trace.h | 37 +++-
> include/linux/iomap.h | 56 ++
> 4 files changed, 172 insertions(+), 1 deletion(-)
> create mode 100644 fs/iomap/core.c
>
> diff --git a/fs/iomap/Makefile b/fs/iomap/Makefile
> index eef2722d93a183..6b56b10ded347a 100644
> --- a/fs/iomap/Makefile
> +++ b/fs/iomap/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_FS_IOMAP)+= iomap.o
>
> iomap-y+= trace.o \
>apply.o \
> + core.o \
>buffered-io.o \
>direct-io.o \
>fiemap.o \
> diff --git a/fs/iomap/core.c b/fs/iomap/core.c
> new file mode 100644
> index 00..89a87a1654e8e6
> --- /dev/null
> +++ b/fs/iomap/core.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2021 Christoph Hellwig.
> + */
> +#include
> +#include
> +#include "trace.h"
> +
> +static inline int iomap_iter_advance(struct iomap_iter *iter)
> +{
> + /* handle the previous iteration (if any) */
> + if (iter->iomap.length) {
> + if (iter->processed <= 0)
> + return iter->processed;
> + if (WARN_ON_ONCE(iter->processed > iomap_length(iter)))
> + return -EIO;
> + iter->pos += iter->processed;
> + iter->len -= iter->processed;
> + if (!iter->len)
> + return 0;
> + }
> +
> + /* clear the state for the next iteration */
> + iter->processed = 0;
> + memset(>iomap, 0, sizeof(iter->iomap));
> + memset(>srcmap, 0, sizeof(iter->srcmap));
> + return 1;
> +}
> +
> +static inline void iomap_iter_done(struct iomap_iter *iter)
> +{
> + WARN_ON_ONCE(iter->iomap.offset > iter->pos);
> + WARN_ON_ONCE(iter->iomap.length == 0);
> + WARN_ON_ONCE(iter->iomap.offset + iter->iomap.length <= iter->pos);
> +
> + trace_iomap_iter_dstmap(iter->inode, >iomap);
> + if (iter->srcmap.type != IOMAP_HOLE)
> + trace_iomap_iter_srcmap(iter->inode, >srcmap);
Given most of the iomap_iter users don't care about srcmap, i.e. are
not COW cases, they are leaving srcmap zero initialized. Should the
IOMAP types be incremented by one so that there is no IOMAP_HOLE
confusion? In other words, fold something like this?
diff --git a/include/linux/iomap.h b/include/linux/iomap.h
index 479c1da3e221..b9c62d0909b0 100644
--- a/include/linux/iomap.h
+++ b/include/linux/iomap.h
@@ -21,14 +21,23 @@ struct page;
struct vm_area_struct;
struct vm_fault;
-/*
- * Types of block ranges for iomap mappings:
+/**
+ * enum iomap_type - Types of block ranges for iomap mappings
+ * @IOMAP_NONE: invalid iomap
+ * @IOMAP_HOLE: no blocks allocated, need allocation
+ * @IOMAP_DELALLOC: delayed allocation blocks
+ * @IOMAP_MAPPED: blocks allocated at @addr
+ * @IOMAP_UNWRITTEN: blocks allocated at @addr in unwritten state
+ * @IOMAP_INLINE: data inline in the inode
*/
-#define IOMAP_HOLE 0 /* no blocks allocated, need allocation */
-#define IOMAP_DELALLOC 1 /* delayed allocation blocks */
-#define IOMAP_MAPPED 2 /* blocks allocated at @addr */
-#define IOMAP_UNWRITTEN3 /* blocks allocated at @addr
in unwritten state */
-#define IOMAP_INLINE 4 /* data inline in the inode */
+enum iomap_type {
+ IOMAP_NONE = 0,
+ IOMAP_HOLE,
+ IOMAP_DELALLOC
+ IOMAP_MAPPED,
+ IOMAP_UNWRITTEN,
+ IOMAP_INLINE,
+};
/*
* Flags reported by the file system from iomap_begin:
> +}
> +
> +/**
> + * iomap_iter - iterate over a ranges in a file
> + * @iter: iteration structue
s/structue/structure/
Other than the minor stuff above, looks good to me:
Reviewed-by: Dan Williams
Re: [Cluster-devel] [PATCH 07/30] fsdax: mark the iomap argument to dax_iomap_sector as const
On Sun, Aug 8, 2021 at 11:19 PM Christoph Hellwig wrote: I'd prefer a non-empty changelog that said something like: "In preparation for iomap_iter() update iomap helpers to treat the iomap argument as read-only." Just to leave a breadcrumb for the motivation for this change, but no major worry if you don't respin for that. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Darrick J. Wong Otherwise, LGTM Reviewed-by: Dan Williams
Re: [Cluster-devel] [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Tue, Oct 13, 2020 at 12:37 PM Matthew Wilcox wrote:
>
> On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 12:52 PM wrote:
> > >
> > > From: Ira Weiny
> > >
> > > The kmap() calls in this FS are localized to a single thread. To avoid
> > > the over head of global PKRS updates use the new kmap_thread() call.
> > >
> > > Cc: Nicolas Pitre
> > > Signed-off-by: Ira Weiny
> > > ---
> > > fs/cramfs/inode.c | 10 +-
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> > > index 912308600d39..003c014a42ed 100644
> > > --- a/fs/cramfs/inode.c
> > > +++ b/fs/cramfs/inode.c
> > > @@ -247,8 +247,8 @@ static void *cramfs_blkdev_read(struct super_block
> > > *sb, unsigned int offset,
> > > struct page *page = pages[i];
> > >
> > > if (page) {
> > > - memcpy(data, kmap(page), PAGE_SIZE);
> > > - kunmap(page);
> > > + memcpy(data, kmap_thread(page), PAGE_SIZE);
> > > + kunmap_thread(page);
> >
> > Why does this need a sleepable kmap? This looks like a textbook
> > kmap_atomic() use case.
>
> There's a lot of code of this form. Could we perhaps have:
>
> static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> int size)
> {
> char *vto = kmap_atomic(to);
>
> memcpy(vto, vfrom, size);
> kunmap_atomic(vto);
> }
>
> in linux/highmem.h ?
Nice, yes, that could also replace the local ones in lib/iov_iter.c
(memcpy_{to,from}_page())
Re: [Cluster-devel] [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Fri, Oct 9, 2020 at 12:52 PM wrote:
>
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
> ---
> fs/cramfs/inode.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> index 912308600d39..003c014a42ed 100644
> --- a/fs/cramfs/inode.c
> +++ b/fs/cramfs/inode.c
> @@ -247,8 +247,8 @@ static void *cramfs_blkdev_read(struct super_block *sb,
> unsigned int offset,
> struct page *page = pages[i];
>
> if (page) {
> - memcpy(data, kmap(page), PAGE_SIZE);
> - kunmap(page);
> + memcpy(data, kmap_thread(page), PAGE_SIZE);
> + kunmap_thread(page);
Why does this need a sleepable kmap? This looks like a textbook
kmap_atomic() use case.
