Messages in this thread | | | Date | Thu, 26 Dec 2013 11:00:49 -0800 | Subject | Re: [RFC] speeding up the stat() family of system calls... | From | Linus Torvalds <> |
| |
On Tue, Dec 24, 2013 at 12:46 PM, Ingo Molnar <mingo@kernel.org> wrote: > > Looks cool - it looks rather similar to the try/catch model Richard > Henderson came up with many eons ago when we implemented the original > exception mechanism for Linux, which IIRC we decided wasn't safe due > to lack of compiler support. > > Now we have compiler support ... written by Richard Henderson ;-)
Interestingly, looking at the cp_new_stat() profiles, the games we play to get efficient range checking seem to actually hurt us. Maybe it's the "sbb" that is just expensive, or maybe it's turning a (very predictable) conditional branch into a data dependency chain instead. Or maybe it's just random noise in my profiles that happened to make those sbb's look bad.
What do people think about this access_ok() simplification that gets rid of inline asm, and instead optimizes the (reasonably common) case of a constant size. The complex case that requires overflow checking *might* get a bit slower (it's not clear: it really wasn't generating wonderful code), but the simple case of a known constant size actually gets simpler.
Random aside: this simplification made the special spurious access_ok() check in kernel/futex.c (the NULL user pointer check in futex_init()) just go away entirely, because the compiler could now see that it can never trigger for a NULL pointer.. Not a performance issue, but it was kind of funny to notice how getting rid of the inline asm actually made the compiler able to notice that.
Linus [unhandled content-type:application/octet-stream] | |