Re: [RFC] what to do with IOCB_DSYNC?

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

On Sun, May 22, 2022 at 12:15:59PM +0100, Matthew Wilcox wrote:
> On Sun, May 22, 2022 at 10:36:00AM +0000, Al Viro wrote:
> > On Sun, May 22, 2022 at 11:23:43AM +0100, Matthew Wilcox wrote:
> > > On Sun, May 22, 2022 at 09:45:09AM +0200, Christoph Hellwig wrote:
> > > > On Sat, May 21, 2022 at 04:14:07PM -0600, Jens Axboe wrote:
> > > > > Then we're almost on par, and it looks like we just need to special case
> > > > > iov_iter_advance() for the nr_segs == 1 as well to be on par. This is on
> > > > > top of your patch as well, fwiw.
> > > > > 
> > > > > It might make sense to special case the single segment cases, for both
> > > > > setup, iteration, and advancing. With that, I think we'll be where we
> > > > > want to be, and there will be no discernable difference between the iter
> > > > > paths and the old style paths.
> > > > 
> > > > A while ago willy posted patches to support a new ITER type for direct
> > > > userspace pointer without iov.  It might be worth looking through the
> > > > archives and test that.
> > > 
> > > https://lore.kernel.org/linux-fsdevel/Yba+YSF6mkM%2FGYlK@casper.infradead.org/
> > 
> > 	Direct kernel pointer, surely?  And from a quick look,
> > iov_iter_is_kaddr() checks for the wrong value...
> 
> Indeed.  I didn't test it; it was a quick patch to see if the idea was
> worth pursuing.  Neither you nor Christoph thought so at the time, so
> I dropped it.  if there are performance improvements to be had from
> doing something like that, it's a more compelling idea than just "Hey,
> this removes a few lines of code and a bit of stack space from every
> caller".

Depends; I rather doubt that it would be useful for kvec case, but iovec
one like that...  The only thing that worries me here is the code generation
for the cascades of ifs in lib/iov_iter.c - that'd need profiling.

And it's orthogonal to the overhead in new_sync_{read,write}(), obviously.