On 5/22/22 7:50 PM, Jens Axboe wrote: > On 5/22/22 7:28 PM, Jens Axboe wrote: >> On 5/22/22 7:22 PM, Jens Axboe wrote: >>> On 5/22/22 6:42 PM, Al Viro wrote: >>>> On Sun, May 22, 2022 at 02:03:35PM -0600, Jens Axboe wrote: >>>> >>>>> Right, I'm saying it's not _immediately_ clear which cases are what when >>>>> reading the code. >>>>> >>>>>> up a while ago. And no, turning that into indirect calls ended up with >>>>>> arseloads of overhead, more's the pity... >>>>> >>>>> It's a shame, since indirect calls make for nicer code, but it's always >>>>> been slower and these days even more so. >>>>> >>>>>> Anyway, at the moment I have something that builds; hadn't tried to >>>>>> boot it yet. >>>>> >>>>> Nice! >>>> >>>> Boots and survives LTP and xfstests... Current variant is in >>>> vfs.git#work.iov_iter (head should be at 27fa77a9829c). I have *not* >>>> looked into the code generation in primitives; the likely/unlikely on >>>> those cascades of ifs need rethinking. >>> >>> I noticed too. Haven't fiddled much in iov_iter.c, but for uio.h I had >>> the below. iov_iter.c is a worse "offender" though, with 53 unlikely and >>> 22 likely annotations... >> >> Here it is... > > Few more, most notably making sure that dio dirties reads even if they > are not of the iovec type. > > Last two just add a helper for import_ubuf() and then adopts it for > io_uring send/recv which is also a hot path. The single range read/write > can be converted too, but that needs a bit more work... Branch here: https://git.kernel.dk/cgit/linux-block/log/?h=iov-iter First 5 are generic ones, and some of them should just be folded with your changes. Last 2 are just converting io_uring to use it where appropriate. We can also use it for vectored readv/writev and recvmsg/sendmsg with one segment. The latter is mostly single segment in the real world anyway, former probably too. Though not sure it's worth it when we're copying a single iovec first anyway? Something to test... -- Jens Axboe
