linux-kernel - RE: [PATCH v1 2/6] iov_iter: optimise bvec iov_iter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c5f54cb816564f2b96f5d7a0f85fdc4a@AcuMS.aculab.com>
Date:   Tue, 15 Dec 2020 13:54:16 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Pavel Begunkov' <asml.silence@...il.com>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>
CC:     Jens Axboe <axboe@...nel.dk>,
        Christoph Hellwig <hch@...radead.org>,
        Matthew Wilcox <willy@...radead.org>,
        Ming Lei <ming.lei@...hat.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        "Darrick J . Wong" <darrick.wong@...cle.com>,
        "Martin K . Petersen" <martin.petersen@...cle.com>,
        Jonathan Corbet <corbet@....net>,
        "linux-xfs@...r.kernel.org" <linux-xfs@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "io-uring@...r.kernel.org" <io-uring@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "target-devel@...r.kernel.org" <target-devel@...r.kernel.org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: RE: [PATCH v1 2/6] iov_iter: optimise bvec iov_iter_advance()

From: Pavel Begunkov
> Sent: 15 December 2020 11:24
> 
> 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.

I knew I didn't have that path - the sources I looked at aren't that new.
Didn't know its state.

In any case that just stops the same test being done twice.
In still changes the order of the tests.

The three 'unlikely' cases should really be inside a single
'unlikely' test for all three bits.
Then there is only one mis-predictable jump prior to the usual path.

By adding the test before iterate_and_advance() you are (effectively)
optimising for the bvec (and discard) cases.
Adding 'unlikely()' won't make any difference on some architectures.
IIRC recent intel x86 don't have a 'static prediction' for unknown
branches - they just use whatever in is the branch predictor tables.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)