On 9/9/21 9:11 PM, Al Viro wrote:

On Thu, Sep 09, 2021 at 09:05:13PM -0600, Jens Axboe wrote:

quoted

On 9/9/21 8:57 PM, Al Viro wrote:

quoted

On Thu, Sep 09, 2021 at 03:19:56PM -0600, Jens Axboe wrote:

quoted

Not sure how we'd do that, outside of stupid tricks like copy the
iov_iter before we pass it down. But that's obviously not going to be
very efficient. Hence we're left with having some way to reset/reexpand,
even in the presence of someone having done truncate on it.

"Obviously" why, exactly?  It's not that large a structure; it's not
the optimal variant, but I'd like to see profiling data before assuming
that it'll cause noticable slowdowns.

It's 48 bytes, and we have to do it upfront. That means we'd be doing it
for _all_ requests, not just when we need to retry. As an example, current
benchmarks are at ~4M read requests per core. That'd add ~200MB/sec of
memory traffic just doing this copy.

Umm...  How much of that will be handled by cache?

Depends? And what if the iovec itself has been modified in the middle?
We'd need to copy that whole thing too. It's just not workable as a
solution.

quoted

Besides, I think that's moot as there's a better way.

I hope so, but I'm afraid that "let's reload from userland on e.g. short
reads" is not better - there's a plenty of interesting corner cases you
need to handle with that.

As long as we're still in the context of the submission, it is tractable
provided we import it like we did originally.

-- 
Jens Axboe