[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8722207799c342e780e1162a983dc48b@AcuMS.aculab.com>
Date: Wed, 16 Aug 2023 08:30:52 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'David Howells' <dhowells@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>
CC: Alexander Viro <viro@...iv.linux.org.uk>,
Jens Axboe <axboe@...nel.dk>, Christoph Hellwig <hch@....de>,
Christian Brauner <christian@...uner.io>,
Matthew Wilcox <willy@...radead.org>,
"jlayton@...nel.org" <jlayton@...nel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH v2] iov_iter: Convert iterate*() to inline funcs
From: David Howells
> Sent: 14 August 2023 22:40
>
>
> > _copy_from_iter inc 0x36e -> 0x395 +0x27
>
> Here a disassembly of _copy_from_iter() from unpatched and patched, marked up for
> the different iterator-type branches. To summarise:
>
> UNPATCHED PATCHED
> START LEN START LEN
> ======= ======= ======= =======
> Prologue 0 77 0 76
> UBUF 77 36 76 36
> IOVEC 113 148 112 105
> BVEC 261 159 217 163
> KVEC 420 125 380 116
> XARRAY 545 286 496 374
> DISCARD/Epi 831 42 870 42
> Return 873 - 912 -
>
>
> The overall change in the entire file, according to size, is:
> 19855 744 0 20599 5077 build3/lib/iov_iter.o -- before
> 19739 864 0 20603 507b build3/lib/iov_iter.o -- after
It is harder to compare because of some of the random name changes.
The version of the source I found seems to pass priv2 to functions
that don't use it?
Since the functions aren't inlined you get the cost of passing
the parameters.
This seems to affect the common cases.
Is that all left over from a version that passed function pointers
(with the hope they'd be inlined?).
Just directly inlining the simple copies should help.
I rather hope the should_fail_usercopy() and instrument_copy_xxx()
calls are usually either absent or, at most, nops.
This all seems to have a lot fewer options than last time I looked.
Is it worth optimising the KVEC case with a single buffer?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists