From: Vineet Gupta <Vineet.Gupta1@synopsys.com> To: Al Viro <viro@ZenIV.linux.org.uk> Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Linus Torvalds <torvalds@linux-foundation.org>, Richard Henderson <rth@twiddle.net>, Russell King <linux@armlinux.org.uk>, Will Deacon <will.deacon@arm.com>, Haavard Skinnemoen <hskinnemoen@gmail.com>, Steven Miao <realmz6@gmail.com>, Jesper Nilsson <jesper.nilsson@axis.com>, Mark Salter <msalter@redhat.com>, Yoshinori Sato <ysato@users.sourceforge.jp>, "Richard Kuo" <rkuo@codeaurora.org>, Tony Luck <tony.luck@intel.com>, "Geert Uytterhoeven" <geert@linux-m68k.org>, James Hogan <james.hogan@imgtec.com>, Michal Simek <monstr@monstr.eu>, David Howells <dhowells@redhat.com>, "Ley Foon Tan" <lftan@altera.com>, Jonas Bonn <Jonas.Nilsson@synopsys.com> Subject: Re: [RFC][CFT][PATCHSET v1] uaccess unification Date: Wed, 29 Mar 2017 14:14:22 -0700 [thread overview] Message-ID: <32129bc4-0e0a-c21d-0e94-67f73a09ac6e@synopsys.com> (raw) In-Reply-To: <20170329202939.GI29622@ZenIV.linux.org.uk> On 03/29/2017 01:29 PM, Al Viro wrote: > On Wed, Mar 29, 2017 at 01:08:12PM -0700, Vineet Gupta wrote: > >> Hi Al, >> >> Thx for taking this up. It seems ARC was missing INLINE_COPY* switch likely due to >> existing 2 variants (inline/out-of-line) we already have. >> I've added a patch for that (attached too) - boot tested the series on ARC. > > BTW, I wonder if inlining all of the copy_{to,from}_user() is actually a win. Just to be clear, your series was doing this for everyone. > It's probably arch-dependent and it would be nice if somebody compared > performance with and without inlining those... ARC, in particular, has > __arc_copy_{to,from}_user() inlining a whole lot, even in case of non-constant > size and your patch, AFAICS, will inline all of it in *all* cases. Yes we do inline all of it: the non-constant case is actually simpler, it is a simple byte loop. " mov.f lp_count, %0 \n" " lpnz 3f \n" " ldb.ab %1, [%3, 1] \n" "1: stb.ab %1, [%2, 1] \n" " sub %0, %0, 1 \n" Doing it out of line (3 args) will be 4 instructions anyways. For constant size, there's laddered copy for blocks of 16 bytes + stragglers 1-15. We do "manual" constant propagation there to compile time optimize away the straggler part. But yes all of this is emitted inline. > It might > end up being a win, but that's not apriori obvious... Do you have any > profiling results in that area? Unfortunately not at the moment. The reason for adding out-of-line variant was not so much as performance but to improve the footprint for -Os case (some customer I think).
WARNING: multiple messages have this Message-ID (diff)
From: Vineet Gupta <Vineet.Gupta1@synopsys.com> To: Al Viro <viro@ZenIV.linux.org.uk> Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Linus Torvalds <torvalds@linux-foundation.org>, Richard Henderson <rth@twiddle.net>, Russell King <linux@armlinux.org.uk>, Will Deacon <will.deacon@arm.com>, Haavard Skinnemoen <hskinnemoen@gmail.com>, Steven Miao <realmz6@gmail.com>, Jesper Nilsson <jesper.nilsson@axis.com>, Mark Salter <msalter@redhat.com>, Yoshinori Sato <ysato@users.sourceforge.jp>, Richard Kuo <rkuo@codeaurora.org>, Tony Luck <tony.luck@intel.com>, Geert Uytterhoeven <geert@linux-m68k.org>, James Hogan <james.hogan@imgtec.com>, Michal Simek <monstr@monstr.eu>, David Howells <dhowells@redhat.com>, Ley Foon Tan <lftan@altera.com>, Jonas Bonn <Jona> Subject: Re: [RFC][CFT][PATCHSET v1] uaccess unification Date: Wed, 29 Mar 2017 14:14:22 -0700 [thread overview] Message-ID: <32129bc4-0e0a-c21d-0e94-67f73a09ac6e@synopsys.com> (raw) In-Reply-To: <20170329202939.GI29622@ZenIV.linux.org.uk> On 03/29/2017 01:29 PM, Al Viro wrote: > On Wed, Mar 29, 2017 at 01:08:12PM -0700, Vineet Gupta wrote: > >> Hi Al, >> >> Thx for taking this up. It seems ARC was missing INLINE_COPY* switch likely due to >> existing 2 variants (inline/out-of-line) we already have. >> I've added a patch for that (attached too) - boot tested the series on ARC. > > BTW, I wonder if inlining all of the copy_{to,from}_user() is actually a win. Just to be clear, your series was doing this for everyone. > It's probably arch-dependent and it would be nice if somebody compared > performance with and without inlining those... ARC, in particular, has > __arc_copy_{to,from}_user() inlining a whole lot, even in case of non-constant > size and your patch, AFAICS, will inline all of it in *all* cases. Yes we do inline all of it: the non-constant case is actually simpler, it is a simple byte loop. " mov.f lp_count, %0 \n" " lpnz 3f \n" " ldb.ab %1, [%3, 1] \n" "1: stb.ab %1, [%2, 1] \n" " sub %0, %0, 1 \n" Doing it out of line (3 args) will be 4 instructions anyways. For constant size, there's laddered copy for blocks of 16 bytes + stragglers 1-15. We do "manual" constant propagation there to compile time optimize away the straggler part. But yes all of this is emitted inline. > It might > end up being a win, but that's not apriori obvious... Do you have any > profiling results in that area? Unfortunately not at the moment. The reason for adding out-of-line variant was not so much as performance but to improve the footprint for -Os case (some customer I think).
next prev parent reply other threads:[~2017-03-29 21:15 UTC|newest] Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-29 5:57 [RFC][CFT][PATCHSET v1] uaccess unification Al Viro 2017-03-29 5:57 ` Al Viro 2017-03-29 20:08 ` Vineet Gupta 2017-03-29 20:08 ` Vineet Gupta 2017-03-29 20:08 ` Vineet Gupta 2017-03-29 20:29 ` Al Viro 2017-03-29 20:29 ` Al Viro 2017-03-29 20:37 ` Linus Torvalds 2017-03-29 20:37 ` Linus Torvalds 2017-03-29 21:03 ` Al Viro 2017-03-29 21:03 ` Al Viro 2017-03-29 21:24 ` Linus Torvalds 2017-03-29 21:24 ` Linus Torvalds 2017-03-29 23:09 ` Al Viro 2017-03-29 23:09 ` Al Viro 2017-03-29 23:43 ` Linus Torvalds 2017-03-29 23:43 ` Linus Torvalds 2017-03-30 15:31 ` Al Viro 2017-03-30 15:31 ` Al Viro 2017-03-29 21:14 ` Vineet Gupta [this message] 2017-03-29 21:14 ` Vineet Gupta 2017-03-29 23:42 ` Al Viro 2017-03-29 23:42 ` Al Viro 2017-03-30 0:02 ` Vineet Gupta 2017-03-30 0:02 ` Vineet Gupta 2017-03-30 0:27 ` Linus Torvalds 2017-03-30 0:27 ` Linus Torvalds 2017-03-30 1:15 ` Al Viro 2017-03-30 1:15 ` Al Viro 2017-03-30 20:40 ` Vineet Gupta 2017-03-30 20:40 ` Vineet Gupta 2017-03-30 20:59 ` Linus Torvalds 2017-03-30 20:59 ` Linus Torvalds 2017-03-30 23:21 ` Russell King - ARM Linux 2017-03-30 23:21 ` Russell King - ARM Linux 2017-03-30 12:32 ` Martin Schwidefsky 2017-03-30 12:32 ` Martin Schwidefsky 2017-03-30 14:48 ` Al Viro 2017-03-30 14:48 ` Al Viro 2017-03-30 16:22 ` Russell King - ARM Linux 2017-03-30 16:22 ` Russell King - ARM Linux 2017-03-30 16:43 ` Al Viro 2017-03-30 16:43 ` Al Viro 2017-03-30 17:18 ` Linus Torvalds 2017-03-30 17:18 ` Linus Torvalds 2017-03-30 18:48 ` Al Viro 2017-03-30 18:48 ` Al Viro 2017-03-30 18:54 ` Al Viro 2017-03-30 18:54 ` Al Viro 2017-03-30 18:59 ` Linus Torvalds 2017-03-30 18:59 ` Linus Torvalds 2017-03-30 19:10 ` Al Viro 2017-03-30 19:10 ` Al Viro 2017-03-30 19:19 ` Linus Torvalds 2017-03-30 19:19 ` Linus Torvalds 2017-03-30 21:08 ` Al Viro 2017-03-30 21:08 ` Al Viro 2017-03-30 18:56 ` Linus Torvalds 2017-03-30 18:56 ` Linus Torvalds 2017-03-31 0:21 ` Kees Cook 2017-03-31 0:21 ` Kees Cook 2017-03-31 13:38 ` James Hogan 2017-03-31 13:38 ` James Hogan 2017-04-03 16:27 ` James Morse 2017-04-03 16:27 ` James Morse 2017-04-04 20:26 ` Max Filippov 2017-04-04 20:26 ` Max Filippov 2017-04-04 20:26 ` Max Filippov 2017-04-04 20:52 ` Al Viro 2017-04-04 20:52 ` Al Viro 2017-04-05 5:05 ` ia64 exceptions (Re: [RFC][CFT][PATCHSET v1] uaccess unification) Al Viro 2017-04-05 5:05 ` Al Viro 2017-04-05 8:08 ` Al Viro 2017-04-05 8:08 ` Al Viro 2017-04-05 18:44 ` Tony Luck 2017-04-05 18:44 ` Tony Luck 2017-04-05 20:33 ` Al Viro 2017-04-05 20:33 ` Al Viro 2017-04-07 0:24 ` [RFC][CFT][PATCHSET v2] uaccess unification Al Viro 2017-04-07 0:24 ` Al Viro 2017-04-07 0:35 ` Al Viro 2017-04-07 0:35 ` Al Viro [not found] <CACVxJT8+fQqvpSPb9rTWFy6g7moqUqxi+Ewjcg0ykuqo=vm4Ow@mail.gmail.com> 2017-03-30 13:27 ` [RFC][CFT][PATCHSET v1] " Alexey Dobriyan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=32129bc4-0e0a-c21d-0e94-67f73a09ac6e@synopsys.com \ --to=vineet.gupta1@synopsys.com \ --cc=Jonas.Nilsson@synopsys.com \ --cc=dhowells@redhat.com \ --cc=geert@linux-m68k.org \ --cc=hskinnemoen@gmail.com \ --cc=james.hogan@imgtec.com \ --cc=jesper.nilsson@axis.com \ --cc=lftan@altera.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=monstr@monstr.eu \ --cc=msalter@redhat.com \ --cc=realmz6@gmail.com \ --cc=rkuo@codeaurora.org \ --cc=rth@twiddle.net \ --cc=tony.luck@intel.com \ --cc=torvalds@linux-foundation.org \ --cc=viro@ZenIV.linux.org.uk \ --cc=will.deacon@arm.com \ --cc=ysato@users.sourceforge.jp \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.