| Message ID | 20200728173216.7184-2-willy@infradead.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Avoid indirect function calls in iomap | expand |
On Tue, Jul 28, 2020 at 06:32:14PM +0100, Matthew Wilcox (Oracle) wrote: > The iomap_iter provides a convenient way to package up and maintain > all the arguments to the various mapping and operation functions. > iomi_advance() moves the iterator forward to the next chunk of the file. > This approach has only one callback to the filesystem -- the iomap_next_t > instead of the separate iomap_begin / iomap_end calls. This slightly > complicates the filesystems, but is more efficient. The next function How much more efficient? I've wondered since the start of spectre/meltdown if in ten years we're still going to appreciate the increase in code complexity that comes from trying to avoid indirect function calls. That said, we needed an iomap iterator long before that, so I think I mostly like this. > will be called even after an error has occurred to allow the filesystem > the opportunity to clean up. > > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> > --- > fs/iomap/apply.c | 29 ++++++++++++++++++++++ > include/linux/iomap.h | 57 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 86 insertions(+) > > diff --git a/fs/iomap/apply.c b/fs/iomap/apply.c > index 76925b40b5fd..c83dcd203558 100644 > --- a/fs/iomap/apply.c > +++ b/fs/iomap/apply.c > @@ -92,3 +92,32 @@ iomap_apply(struct inode *inode, loff_t pos, loff_t length, unsigned flags, > > return written ? written : ret; > } > + > +bool iomi_advance(struct iomap_iter *iomi, int err) > +{ > + struct iomap *iomap = &iomi->iomap; > + > + if (likely(!err)) { > + iomi->pos += iomi->copied; > + iomi->len -= iomi->copied; > + iomi->ret += iomi->copied; > + if (!iomi->len) > + return false; > + iomi->copied = 0; > + if (WARN_ON(iomap->offset > iomi->pos)) > + err = -EIO; > + if (WARN_ON(iomap->offset + iomap->length <= iomi->pos)) > + err = -EIO; > + } > + > + if (unlikely(err < 0)) { > + if (iomi->copied < 0) > + return false; > + /* Give the body a chance to see the error and clean up */ > + iomi->copied = err; > + if (!iomi->ret) > + iomi->ret = err; > + } > + return true; > +} > +EXPORT_SYMBOL_GPL(iomi_advance); > diff --git a/include/linux/iomap.h b/include/linux/iomap.h > index 4d1d3c3469e9..fe58e68ec0c1 100644 > --- a/include/linux/iomap.h > +++ b/include/linux/iomap.h > @@ -142,6 +142,63 @@ struct iomap_ops { > ssize_t written, unsigned flags, struct iomap *iomap); > }; > > +/** > + * struct iomap_iter - Iterate through a range of a file. > + * @inode: Set at the start of the iteration and should not change. > + * @pos: The current file position we are operating on. It is updated by > + * calls to iomap_iter(). Treat as read-only in the body. > + * @len: The remaining length of the file segment we're operating on. > + * It is updated at the same time as @pos. > + * @ret: What we want our declaring function to return. It is initialised > + * to zero and is the cumulative number of bytes processed so far. > + * It is updated at the same time as @pos. > + * @copied: The number of bytes operated on by the body in the most > + * recent iteration. If no bytes were operated on, it may be set to > + * a negative errno. 0 is treated as -EIO. > + * @flags: Zero or more of the iomap_begin flags above. > + * @iomap: ... > + * @srcma:s ... ...? :) > + */ > +struct iomap_iter { > + struct inode *inode; > + loff_t pos; > + u64 len; Thanks for leaving this u64 :) > + loff_t ret; > + ssize_t copied; Is this going to be sufficient for SEEK_{HOLE,DATA} when it wants to jump ahead by more than 2GB? > + unsigned flags; > + struct iomap iomap; > + struct iomap srcmap; > +}; > + > +#define IOMAP_ITER(name, _inode, _pos, _len, _flags) \ > + struct iomap_iter name = { \ > + .inode = _inode, \ > + .pos = _pos, \ > + .len = _len, \ > + .flags = _flags, \ > + } > + > +typedef int (*iomap_next_t)(const struct iomap_iter *, > + struct iomap *iomap, struct iomap *srcmap); I muttered in my other reply how these probably should be called iomap_iter_advance_t since they actually do the upper level work of advancing the iterator to the next mapping. --D > +bool iomi_advance(struct iomap_iter *iomi, int err); > + > +static inline bool iomap_iter(struct iomap_iter *iomi, iomap_next_t next) > +{ > + if (iomi->ret && iomi->copied == 0) > + iomi->copied = -EIO; > + > + return iomi_advance(iomi, next(iomi, &iomi->iomap, &iomi->srcmap)); > +} > + > +static inline u64 iomap_length(const struct iomap_iter *iomi) > +{ > + u64 end = iomi->iomap.offset + iomi->iomap.length; > + > + if (iomi->srcmap.type != IOMAP_HOLE) > + end = min(end, iomi->srcmap.offset + iomi->srcmap.length); > + return min(iomi->len, end - iomi->pos); > +} > + > /* > * Main iomap iterator function. > */ > -- > 2.27.0 >
On Tue, Aug 11, 2020 at 02:01:27PM -0700, Darrick J. Wong wrote: > On Tue, Jul 28, 2020 at 06:32:14PM +0100, Matthew Wilcox (Oracle) wrote: > > The iomap_iter provides a convenient way to package up and maintain > > all the arguments to the various mapping and operation functions. > > iomi_advance() moves the iterator forward to the next chunk of the file. > > This approach has only one callback to the filesystem -- the iomap_next_t > > instead of the separate iomap_begin / iomap_end calls. This slightly > > complicates the filesystems, but is more efficient. The next function > > How much more efficient? I've wondered since the start of I haven't done any performance measurements. Not entirely sure what I'd do to measure it, to be honest. I suppose I should also note the decreased stack depth here, although I do mention that in the next patch. > > +/** > > + * struct iomap_iter - Iterate through a range of a file. > > + * @inode: Set at the start of the iteration and should not change. > > + * @pos: The current file position we are operating on. It is updated by > > + * calls to iomap_iter(). Treat as read-only in the body. > > + * @len: The remaining length of the file segment we're operating on. > > + * It is updated at the same time as @pos. > > + * @ret: What we want our declaring function to return. It is initialised > > + * to zero and is the cumulative number of bytes processed so far. > > + * It is updated at the same time as @pos. > > + * @copied: The number of bytes operated on by the body in the most > > + * recent iteration. If no bytes were operated on, it may be set to > > + * a negative errno. 0 is treated as -EIO. > > + * @flags: Zero or more of the iomap_begin flags above. > > + * @iomap: ... > > + * @srcma:s ... > > ...? :) I ran out of tuits. If this approach makes people happy, I can finish it off. > > + */ > > +struct iomap_iter { > > + struct inode *inode; > > + loff_t pos; > > + u64 len; > > Thanks for leaving this u64 :) > > > + loff_t ret; > > + ssize_t copied; > > Is this going to be sufficient for SEEK_{HOLE,DATA} when it wants to > jump ahead by more than 2GB? That's a good point. loff_t, I guess. Even though the current users of iomap don't support extents larger than 2GB ;-) > > + unsigned flags; > > + struct iomap iomap; > > + struct iomap srcmap; > > +}; > > + > > +#define IOMAP_ITER(name, _inode, _pos, _len, _flags) \ > > + struct iomap_iter name = { \ > > + .inode = _inode, \ > > + .pos = _pos, \ > > + .len = _len, \ > > + .flags = _flags, \ > > + } > > + > > +typedef int (*iomap_next_t)(const struct iomap_iter *, > > + struct iomap *iomap, struct iomap *srcmap); > > I muttered in my other reply how these probably should be called > iomap_iter_advance_t since they actually do the upper level work of > advancing the iterator to the next mapping. nono, the iterator is const! They don't move the iterator at all, they just get the next iomap/srcmap.
diff --git a/fs/iomap/apply.c b/fs/iomap/apply.c index 76925b40b5fd..c83dcd203558 100644 --- a/fs/iomap/apply.c +++ b/fs/iomap/apply.c @@ -92,3 +92,32 @@ iomap_apply(struct inode *inode, loff_t pos, loff_t length, unsigned flags, return written ? written : ret; } + +bool iomi_advance(struct iomap_iter *iomi, int err) +{ + struct iomap *iomap = &iomi->iomap; + + if (likely(!err)) { + iomi->pos += iomi->copied; + iomi->len -= iomi->copied; + iomi->ret += iomi->copied; + if (!iomi->len) + return false; + iomi->copied = 0; + if (WARN_ON(iomap->offset > iomi->pos)) + err = -EIO; + if (WARN_ON(iomap->offset + iomap->length <= iomi->pos)) + err = -EIO; + } + + if (unlikely(err < 0)) { + if (iomi->copied < 0) + return false; + /* Give the body a chance to see the error and clean up */ + iomi->copied = err; + if (!iomi->ret) + iomi->ret = err; + } + return true; +} +EXPORT_SYMBOL_GPL(iomi_advance); diff --git a/include/linux/iomap.h b/include/linux/iomap.h index 4d1d3c3469e9..fe58e68ec0c1 100644 --- a/include/linux/iomap.h +++ b/include/linux/iomap.h @@ -142,6 +142,63 @@ struct iomap_ops { ssize_t written, unsigned flags, struct iomap *iomap); }; +/** + * struct iomap_iter - Iterate through a range of a file. + * @inode: Set at the start of the iteration and should not change. + * @pos: The current file position we are operating on. It is updated by + * calls to iomap_iter(). Treat as read-only in the body. + * @len: The remaining length of the file segment we're operating on. + * It is updated at the same time as @pos. + * @ret: What we want our declaring function to return. It is initialised + * to zero and is the cumulative number of bytes processed so far. + * It is updated at the same time as @pos. + * @copied: The number of bytes operated on by the body in the most + * recent iteration. If no bytes were operated on, it may be set to + * a negative errno. 0 is treated as -EIO. + * @flags: Zero or more of the iomap_begin flags above. + * @iomap: ... + * @srcma:s ... + */ +struct iomap_iter { + struct inode *inode; + loff_t pos; + u64 len; + loff_t ret; + ssize_t copied; + unsigned flags; + struct iomap iomap; + struct iomap srcmap; +}; + +#define IOMAP_ITER(name, _inode, _pos, _len, _flags) \ + struct iomap_iter name = { \ + .inode = _inode, \ + .pos = _pos, \ + .len = _len, \ + .flags = _flags, \ + } + +typedef int (*iomap_next_t)(const struct iomap_iter *, + struct iomap *iomap, struct iomap *srcmap); +bool iomi_advance(struct iomap_iter *iomi, int err); + +static inline bool iomap_iter(struct iomap_iter *iomi, iomap_next_t next) +{ + if (iomi->ret && iomi->copied == 0) + iomi->copied = -EIO; + + return iomi_advance(iomi, next(iomi, &iomi->iomap, &iomi->srcmap)); +} + +static inline u64 iomap_length(const struct iomap_iter *iomi) +{ + u64 end = iomi->iomap.offset + iomi->iomap.length; + + if (iomi->srcmap.type != IOMAP_HOLE) + end = min(end, iomi->srcmap.offset + iomi->srcmap.length); + return min(iomi->len, end - iomi->pos); +} + /* * Main iomap iterator function. */
The iomap_iter provides a convenient way to package up and maintain all the arguments to the various mapping and operation functions. iomi_advance() moves the iterator forward to the next chunk of the file. This approach has only one callback to the filesystem -- the iomap_next_t instead of the separate iomap_begin / iomap_end calls. This slightly complicates the filesystems, but is more efficient. The next function will be called even after an error has occurred to allow the filesystem the opportunity to clean up. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> --- fs/iomap/apply.c | 29 ++++++++++++++++++++++ include/linux/iomap.h | 57 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 86 insertions(+)