https://bugzilla.suse.com/show_bug.cgi?id=1177403 https://bugzilla.suse.com/show_bug.cgi?id=1177403#c2 Mel Gorman <mgorman@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mgorman@suse.com --- Comment #2 from Mel Gorman <mgorman@suse.com> --- The cost of failing to inline is variable as it depends on the paths affected. Generally it's observable through perf by noting new functions that have a lot of samples taken on the function entry and exit points where the stack is modified and initialised. It was recently noted that inling cost about 1% in page fault paths due to excess time spent on function entry/exit that could be reduced by modifying code to force the inlining due to CONFIG_STACKPROTECTOR_STRONG. As well as affecting inlining, that option affects functions that initialise many stack variables and then make a cheap check on whether the function is even necessary. Prior to CONFIG_STACKPROTECTOR_STRONG, the check could be done before stack initialising but not any more. While an evaluation could be done on this, it'll likely be inconclusive as it'll simply show higher cost on function entry/exit which has a small impact on multiple paths. The effect can be detected but will also be close to the noise. The real qusetion is -- why enable this at all for a production build? It would make more sense to build with this option when considering whether a branch should be merged or not and mail when new warnings are added due to section mismatches. -- You are receiving this mail because: You are on the CC list for the bug.