User: Password:
|
|
Subscribe / Log in / New account

What's coming in $NEXT_KERNEL_VERSION, part 1

What's coming in $NEXT_KERNEL_VERSION, part 1

Posted May 26, 2011 18:03 UTC (Thu) by nevets (subscriber, #11875)
In reply to: What's coming in $NEXT_KERNEL_VERSION, part 1 by pr1268
Parent article: What's coming in $NEXT_KERNEL_VERSION, part 1

For you first question, yes. The kernel does not link to any other library. Basically everything used by the kernel is defined by the kernel. Standard C libraries do too much that is not allowed in the kernel (like any floating point operations).

The kstrtol_from_user() does much more than strtol. That "from_user" part is critical. It is accessing data from an untrusted source. It must be prepared for that address to segfault, and make sure it does not belong to something that the user should not be touching.

For your second question, well, that's the point for switching back to -O2 :) The idea was that a smaller kernel would have less pressure on the instruction cache and be a bigger win in performance. Anytime you take a miss in the instruction cache, the CPU must stall to retrieve the memory that contains the instructions. As CPUs are much faster than memory access, the less you miss instruction cache, the faster you run. But if the -Os is not affecting this much at all, there's no point in using it.


(Log in to post comments)

What's coming in $NEXT_KERNEL_VERSION, part 1

Posted May 27, 2011 22:01 UTC (Fri) by oak (guest, #2786) [Link]

I think that at some point during v4.x development, gcc -Os option was changed from producing smaller code without much performance hit to something that mainly aims at smaller code. If I remember right, there was even a gcc bug filed by Mozilla devs about this as they thought it a regression...

What's coming in $NEXT_KERNEL_VERSION, part 1

Posted May 31, 2011 13:17 UTC (Tue) by pbonzini (subscriber, #60935) [Link]

> gcc -Os option was changed from producing smaller code without much
> performance hit to something that mainly aims at smaller code

That actually had always been the aim, but the tuning was not so good. For example, Mozilla was making some simple functions non-static that should have been static. These functions were very simple, but they were used only once and they still had to be included in the final binary. So GCC started being worried about including two copies of them and stopped inlining them. (This was fixed by tuning inliner heuristics to detect the optimization opportunities coming from the inlining of such simple functions).


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds