On Sun, May 22, 2022 at 02:03:35PM -0600, Jens Axboe wrote:
> Right, I'm saying it's not _immediately_ clear which cases are what when
> reading the code.
>
> > up a while ago. And no, turning that into indirect calls ended up with
> > arseloads of overhead, more's the pity...
>
> It's a shame, since indirect calls make for nicer code, but it's always
> been slower and these days even more so.
>
> > Anyway, at the moment I have something that builds; hadn't tried to
> > boot it yet.
>
> Nice!
Boots and survives LTP and xfstests... Current variant is in vfs.git#work.iov_iter
(head should be at 27fa77a9829c). I have *not* looked into the code generation
in primitives; the likely/unlikely on those cascades of ifs need rethinking.
I hadn't added ITER_KBUF (or KADDR, whatever); should be an easy incremental,
though.
At the moment it's carved up into 6 commits:
btrfs_direct_write(): cleaner way to handle generic_write_sync() suppression
struct file: use anonymous union member for rcuhead and llist
iocb: delay evaluation of IS_SYNC(...) until we want to check IOCB_DSYNC
keep iocb_flags() result cached in struct file
new iov_iter flavour - ITER_UBUF
switch new_sync_{read,write}() to ITER_UBUF
Review and testing would be welcome, but it's obviously not this window fodder.
