Re: [RFC] what to do with IOCB_DSYNC?

From: Al Viro <viro@zeniv.linux.org.uk>
To: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@lst.de>,
	Matthew Wilcox <willy@infradead.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [RFC] what to do with IOCB_DSYNC?
Date: Mon, 23 May 2022 00:42:33 +0000	[thread overview]
Message-ID: <YorYeQpW9nBJEeSx@zeniv-ca.linux.org.uk> (raw)
In-Reply-To: <1b2cb369-2247-8c10-bd6e-405a8167f795@kernel.dk>

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.