On Thu, Mar 30, 2023 at 9:47 AM Jens Axboe <axboe@xxxxxxxxx> wrote:
>
> Sadly, in absolute numbers, comparing read(2) and readv(2),
> the latter takes 2.11x as long in the stock kernel, and 2.01x as long
> with the patches. So while single segment is better now than before,
> it's still waaaay slower than having to copy in a single iovec. Testing
> was run with all security mitigations off.
What does the profile say? Iis it all in import_iovec() or what?
I do note that we have some completely horrid "helper" functions in
the iter paths: things like "do_iter_readv_writev()" supposedly being
a common function , but then it ends up doing some small setup and
just doing a conditional on the "type" after all, so when it isn't
inlined, you have those things that don't predict well at all.
And the iter interfaces don't have just that iterator, they have the
whole kiocb overhead too. All in the name of being generic. Most file
descriptors don't even support the simpler ".read" interface, because
they want the whole thing with IOCB_DIRECT flags etc.
So to some degree it's unfair to compare read-vs-read_iter. The latter
has all that disgusting support for O_DIRECT and friends, and testing
with /dev/null just doesn't show that part.
Linus
