From: David Howells > Sent: Wednesday, August 16, 2023 10:50 AM > > David Laight <David.Laight@xxxxxxxxxx> wrote: > > > It is harder to compare because of some of the random name changes. > > I wouldn't say 'random' exactly, but if you prefer, some of the name changing > can be split out into a separate patch. The macros are kind of the worst > since they picked up variable names from the callers. > > > The version of the source I found seems to pass priv2 to functions > > that don't use it? > > That can't be avoided if I convert everything to inline functions and function > pointers - but the optimiser can get rid of it where it can inline the step > function. AFAICT the IOVEC one was only called directly. > I tried passing the iterator to the step functions instead, but that just made > things bigger. memcpy_from_iter_mc() is interesting to deal with. I would > prefer to deal with it in the caller so we only do the check once, but that > might mean duplicating the caller. You could try something slightly horrid that the compiler might optimise for you. Instead of passing in a function pointer pass a number. Then do something like: #define call_iter(id, ...) \ (id == x ? fn_x(__VA_ARGS__) : id == y ? fn_y(__VA_ARGS) ...) constant folding on the inline should kill the function pointer. You might get away with putting the args on the end. ... > > I rather hope the should_fail_usercopy() and instrument_copy_xxx() > > calls are usually either absent or, at most, nops. > > Okay - it's probably worth marking those too, then. Thinking I'm sure they are KASAN annotations. The are few enough calls that I suspect that replicating them won't affect KASAN (etc) builds. > > This all seems to have a lot fewer options than last time I looked. > > I'm not sure what you mean by 'a lot fewer options'? It might just be ITER_PIPE that has gone. > > Is it worth optimising the KVEC case with a single buffer? > > You mean an equivalent of UBUF? Maybe. There are probably a whole bunch of > netfs places that do single-kvec writes, though I'm trying to convert these > over to bvec arrays, combining them with their data, and MSG_SPLICE_PAGES. I'm thinking of what happens with kernel callers of things like the socket code - especially for address/option buffers. Probably io_uring and bpf (and my out of tree drivers!). Could be the equivalent of UBUF, but checking for KVEC with a count of 1 wouldn't really add any more cmp/jmp pairs. I've also noticed in the past that some of this code seems to be optimised for zero length buffers/fragments. Surely they just need to work? David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
