From: David Howells

Sent: Wednesday, August 16, 2023 10:50 AM

David Laight [off-list ref] wrote:

quoted

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.

quoted

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.

...

quoted

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.

quoted

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.

quoted

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)