On 5/22/22 6:42 PM, Al Viro wrote:
> 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 noticed too. Haven't fiddled much in iov_iter.c, but for uio.h I had
the below. iov_iter.c is a worse "offender" though, with 53 unlikely and
22 likely annotations...
> 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.
I'll take a look at it tomorrow, but did run a quick test on my vm and
it looks good. It's < 1% now for me, which is a big improvement.
--
Jens Axboe
