Re: [RFC] what to do with IOCB_DSYNC?

[Jens Axboe <axboe@kernel.dk>]

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