From: Linus Torvalds <torvalds@linux-foundation.org> To: Vineet Gupta <Vineet.Gupta1@synopsys.com> Cc: Al Viro <viro@zeniv.linux.org.uk>, "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.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: Thu, 30 Mar 2017 13:59:58 -0700 [thread overview] Message-ID: <CA+55aFyQL75SOyx=zn1zWvy+TS-Ockv=O9Q59b_ZQwSeCh7WnQ@mail.gmail.com> (raw) In-Reply-To: <efb7aaa4-7d25-0c68-ebf8-cdd7eb1297dc@synopsys.com> On Thu, Mar 30, 2017 at 1:40 PM, Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote: > > So it's a mix bag really. Maybe we need some better directed test to really drill > it down. As mentioned inn the discussion about ARM, I seriously doubt that the inlining will even be noticeable compared to other effects here. The cases where I've seen this matter have been the small constant-sized copies, and in every case the right fix was to use "get_user()" instead of "copy_from_user()". There are a couple of really special cases that can show up where there's a slightly bigger and more complex case that still is meaningful: the most noticeable of those being "stat()". > So what you are saying is it is relatively costly on x86 because of SMAP which may > not be true for arches w/o hardware support. > Note that I'm not arguing for/against inlining per-se, it seems it doesn't matter So on x86 (and ARM) we have the SMAP/UAO issue, and on other architectures we have another expense entirely: maintenance and testing. (On ARM, hopefully the UAO bit is faster to set, but it's still "another instruction before and after", so even if it's not as expensive as clac/stac are on current x86 chips, it's an argument against inlining) And on the maintenance and testing side, it means that unless some header organization makes sense on x86 or ARM (or power), it likely doesn't make sense to try to tweak for any other architecture. Or at the very least it would have to be a _really_ big and noticeable issue, not something that might be hard/impossible to even measure. Linus
WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org> To: Vineet Gupta <Vineet.Gupta1@synopsys.com> Cc: Al Viro <viro@zeniv.linux.org.uk>, "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.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.> Subject: Re: [RFC][CFT][PATCHSET v1] uaccess unification Date: Thu, 30 Mar 2017 13:59:58 -0700 [thread overview] Message-ID: <CA+55aFyQL75SOyx=zn1zWvy+TS-Ockv=O9Q59b_ZQwSeCh7WnQ@mail.gmail.com> (raw) In-Reply-To: <efb7aaa4-7d25-0c68-ebf8-cdd7eb1297dc@synopsys.com> On Thu, Mar 30, 2017 at 1:40 PM, Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote: > > So it's a mix bag really. Maybe we need some better directed test to really drill > it down. As mentioned inn the discussion about ARM, I seriously doubt that the inlining will even be noticeable compared to other effects here. The cases where I've seen this matter have been the small constant-sized copies, and in every case the right fix was to use "get_user()" instead of "copy_from_user()". There are a couple of really special cases that can show up where there's a slightly bigger and more complex case that still is meaningful: the most noticeable of those being "stat()". > So what you are saying is it is relatively costly on x86 because of SMAP which may > not be true for arches w/o hardware support. > Note that I'm not arguing for/against inlining per-se, it seems it doesn't matter So on x86 (and ARM) we have the SMAP/UAO issue, and on other architectures we have another expense entirely: maintenance and testing. (On ARM, hopefully the UAO bit is faster to set, but it's still "another instruction before and after", so even if it's not as expensive as clac/stac are on current x86 chips, it's an argument against inlining) And on the maintenance and testing side, it means that unless some header organization makes sense on x86 or ARM (or power), it likely doesn't make sense to try to tweak for any other architecture. Or at the very least it would have to be a _really_ big and noticeable issue, not something that might be hard/impossible to even measure. Linus
next prev parent reply other threads:[~2017-03-30 21:00 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 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 [this message] 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='CA+55aFyQL75SOyx=zn1zWvy+TS-Ockv=O9Q59b_ZQwSeCh7WnQ@mail.gmail.com' \ --to=torvalds@linux-foundation.org \ --cc=Jonas.Nilsson@synopsys.com \ --cc=Vineet.Gupta1@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=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.