On Sun, May 22, 2022 at 12:48:20PM -0600, Jens Axboe wrote:
> On 5/22/22 12:39 PM, Al Viro wrote:
> > On Sun, May 22, 2022 at 12:29:16PM -0600, Jens Axboe wrote:
> >> It was sent out as a discussion point, it's not a submission and it's by
> >> no means complete (as mentioned!). If you're working on this, I'd be
> >> happy to drop it, it's not like I really enjoy the iov_iter code... And
> >> it sounds like you are?
> >
> > *snort*
> >
> > Yes, I am working on it. As for enjoying that thing... I'm not fond of
>
> OK great, I'll abandon this sandbox. Let me know when you have something
> to test, and I can compare some numbers between non-iter, iter,
> iter-with-ubuf.
>
> > forests of macros, to put it mildly. Even in the trimmed form it still
> > stinks, and places like copy_page_to_iter for iovec are still fucking
> > awful wrt misguided microoptimization attempts - mine, at that, so I've
> > nobody else to curse ;-/
>
> And it's not even clear which ones won't work with the generic variants,
> and which ones are just an optimization. I suspect a lot of the icache
> bloat from this just makes things worse...
???
copy_page_{from,to}_iter() iovec side is needed not for the sake of
optimizations - if you look at the generic variant, you'll see that it's
basically "kmap_local_page + copy_{to,from}_iter() for the contents +
kunmap_local_page", which obviously relies upon the copy_{to,from}_iter()
being non-blocking. So iovec part of it genuinely needs to differ from
the generic variant; it's just that on top of that it had been (badly)
microoptimized. So were iterators, but that got at least somewhat cleaned
up a while ago. And no, turning that into indirect calls ended up with
arseloads of overhead, more's the pity...
Anyway, at the moment I have something that builds; hadn't tried to boot it yet.
