On 9/10/21 8:42 AM, Al Viro wrote:

On Fri, Sep 10, 2021 at 07:57:49AM -0600, Jens Axboe wrote:

quoted

It was just a quick hack, might very well be too eager to go through
those motions. But pondering this instead of sleeping, we don't need to
copy all of iov_iter in order to restore the state, and we can use the
same advance after restoring. So something like this may be more
palatable. Caveat - again untested, and I haven't tested the performance
impact of this at all.

You actually can cut it down even more - nr_segs + iov remains constant
all along, so you could get away with just 3 words here...  I would be

Mmm, the iov pointer remains constant? Maybe I'm missing your point, but
the various advance functions are quite happy to increment iter->iov or
iter->bvec, so we need to restore them. From a quick look, looks like
iter->nr_segs is modified for advancing too.

What am I missing?

surprised if extra memory traffic had shown up - it's well within the
noise from register spills, (un)inlining, etc.  We are talking about
3 (or 4, with your variant) extra words on one stack frame (and that'd
be further offset by removal of ->truncated); I'd still like to see the
profiling data, but concerns about extra memory traffic due to that
are, IMO, misplaced.

See other email that was just sent out, it is measurable but pretty
minimal. But that's also down to about 1/3rd of copying the whole
thing blindly, so definitely a better case.

-- 
Jens Axboe