On 6/6/22 10:08 PM, Al Viro wrote:
> Rebased to -rc1 and reordered. Sits in vfs.git #work.iov_iter,
> individual patches in followups
>
> 1/9: No need of likely/unlikely on calls of check_copy_size()
> not just in uio.h; the thing is inlined and it has unlikely on
> all paths leading to return false
>
> 2/9: btrfs_direct_write(): cleaner way to handle generic_write_sync() suppression
> new flag for iomap_dio_rw(), telling it to suppress generic_write_sync()
>
> 3/9: struct file: use anonymous union member for rcuhead and llist
> "f_u" might have been an amusing name, but... we expect anon unions to
> work.
>
> 4/9: iocb: delay evaluation of IS_SYNC(...) until we want to check IOCB_DSYNC
> makes iocb_flags() much cheaper, and it's easier to keep track of
> the places where it can change.
>
> 5/9: keep iocb_flags() result cached in struct file
> that, along with the previous commit, reduces the overhead of
> new_sync_{read,write}(). struct file doesn't grow - we can keep that
> thing in the same anon union where rcuhead and llist live; that field
> gets used only before ->f_count reaches zero while the other two are
> used only after ->f_count has reached zero.
>
> 6/9: copy_page_{to,from}_iter(): switch iovec variants to generic
> kmap_local_page() allows that. And it kills quite a bit of
> code.
>
> 7/9: new iov_iter flavour - ITER_UBUF
> iovec analogue, with single segment. That case is fairly common and it
> can be handled with less overhead than full-blown iovec.
>
> 8/9: switch new_sync_{read,write}() to ITER_UBUF
> ... and this is why it is so common. Further reduction of overhead
> for new_sync_{read,write}().
>
> 9/9: iov_iter_bvec_advance(): don't bother with bvec_iter
> AFAICS, variant similar to what we do for iovec/kvec generates better
> code. Needs profiling, obviously.
Al, looks good to me from inspection, and I ported stuffed this on top
of -git and my 5.20 branch, and did my send/recv/recvmsg io_uring change
on top and see a noticeable reduction there too for some benchmarking.
Feel free to add:
Reviewed-by: Jens Axboe <axboe@xxxxxxxxx>
to the series.
Side note - of my initial series I played with, I still have this one
leftover that I do utilize for io_uring:
https://git.kernel.dk/cgit/linux-block/commit/?h=for-5.20/io_uring-iter&id=a59f5c21a6eeb9506163c20aff4846dbec159f47
Doesn't make sense standalone, but I have it as a prep patch.
Can I consider your work.iov_iter stable at this point, or are you still
planning rebasing?
--
Jens Axboe
