On Thu, Mar 30, 2017 at 1:40 PM, Vineet Gupta
<Vineet.Gupta1@xxxxxxxxxxxx> 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
