Re: [RFC] what to do with IOCB_DSYNC?

[Al Viro <viro@zeniv.linux.org.uk>]

On Mon, Jun 21, 2021 at 04:22:35PM +0200, Christoph Hellwig wrote:
> On Mon, Jun 21, 2021 at 03:16:50PM +0100, Matthew Wilcox wrote:
> > On Mon, Jun 21, 2021 at 04:09:56PM +0200, Christoph Hellwig wrote:
> > > On Mon, Jun 21, 2021 at 03:03:07PM +0100, Matthew Wilcox wrote:
> > > > i suggested that to viro last night, and he pointed out that ioctl(S_SYNC)
> > > 
> > > Where would that S_SYNC ioctl be implemented?
> > 
> > xfs_diflags_to_iflags(
> >         if (xflags & FS_XFLAG_SYNC)
> >                 flags |= S_SYNC;
> > 
> > (mutatis mutandi per filesystem)
> 
> 
> Ok, your description above wasn't very exact.

Sorry - the relevant part of conversation went

< viro> willy: that's the part that can't be done at open() time
< willy> because we might mount -o remount,sync after open()?
< viro> ... as well as setting S_SYNC via ioctl

Should've been phrased better...

> Anyway, that at least doesn't go out to the superblock.  But if Al
> dislikes it we can also make generic_sync_file and friends check
> IS_SYNC() again.  Having a single flag is kinda nice as it avoids
> stupid errors, but if we actually have a performance problem here
> (do we have any data on that?) just going back to the old way would
> seem like the simplest fix.

	IIRC, there had been profiling data posted with init_sync_kiocb()
responsible for large part of new_sync_write()/new_sync_read() overhead.
Remember the threads about the use of ->read_iter()/->write_iter() being
slower than having ->read()/->write()?  Back in December or so, I think;
one surprising part had been that large chunk of overhead sat not in
suboptimal iov_iter primitives, but right in new_sync_read()/new_sync_write()
with init_sync_kiocb() being the source of it,

	I'd rather have a single helper for those checks, rather than
open-coding IS_SYNC() + IOCB_DSYNC in each, for obvious reasons...