lkml.org 
[lkml]   [2020]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v1 2/6] iov_iter: optimise bvec iov_iter_advance()
Date
On 15/12/2020 09:37, David Laight wrote:
> From: Pavel Begunkov
>> Sent: 15 December 2020 00:20
>>
>> iov_iter_advance() is heavily used, but implemented through generic
>> iteration. As bvecs have a specifically crafted advance() function, i.e.
>> bvec_iter_advance(), which is faster and slimmer, use it instead.
>>
>> lib/iov_iter.c | 19 +++++++++++++++++++
[...]
>> void iov_iter_advance(struct iov_iter *i, size_t size)
>> {
>> if (unlikely(iov_iter_is_pipe(i))) {
>> @@ -1077,6 +1092,10 @@ void iov_iter_advance(struct iov_iter *i, size_t size)
>> i->count -= size;
>> return;
>> }
>> + if (iov_iter_is_bvec(i)) {
>> + iov_iter_bvec_advance(i, size);
>> + return;
>> + }
>> iterate_and_advance(i, size, v, 0, 0, 0)
>> }
>
> This seems to add yet another comparison before what is probably
> the common case on an IOVEC (ie normal userspace buffer).

If Al finally takes the patch for iov_iter_is_*() helpers it would
be completely optimised out.

>
> Can't the call to bver_iter_advance be dropped into the 'advance'
> path for BVEC's inside iterate_and_advance?

It iterates by page/segment/etc., why would you want to do
bver_iter_advance(i->count) there?

>
> iterate_and_advance itself has three 'unlikely' conditional tests
> that may be mis-predicted taken before the 'likely' path.
> One is for DISCARD which is checked twice on the object I just
> looked at - the test in iov_iter_advance() is pointless.

And again, both second checks, including for discards, would be
optimised out by the iov_iter_is_* patch.

--
Pavel Begunkov

\
 
 \ /
  Last update: 2020-12-15 12:31    [W:0.073 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site