On Sat, Nov 21, 2020 at 10:21:17AM -0800, Linus Torvalds wrote: > So I think conceptually this is the right thing to do, but I have a > couple of worries: > > - do we really need all those different versions? I'm thinking > "iter_full" versions in particular. They I think the iter_full version > could just be wrappers that call the regular iter thing and verify the > end result is full (and revert if not). No? Umm... Not sure - iov_iter_revert() is not exactly light. OTOH, it's on a slow path... Other variants: * save local copy, run of normal variant on iter, then copy the saved back on failure * make a local copy, run the normal variant in _that_, then copy it back on success. Note that the entire thing is 5 words, and we end up reading all of them anyway, so I wouldn't bet which variant ends up being faster - that would need testing to compare. I would certainly like to get rid of the duplication there, especially if we are going to add copy_to_iter_full() and friends (there are use cases for those). > - I worry a bit about the indirect call overhead and spectre v2. > > So yeah, it would be good to have benchmarks to make sure this > doesn't regress for some simple case. > > Other than those things, my initial reaction is "this does seem cleaner". It does seem cleaner, all right, but that stuff is on fairly hot paths. And I didn't want to mix the overhead of indirect calls into the picture, so it turned into cascades of ifs with rather vile macros to keep the size down. It looks like the cost of indirects is noticable. OTOH, there are other iov_iter patches floating around, hopefully getting better code generation. Let's see how much do those give and if they win considerably more than those several percents, revisit this series.
