Comment # 2 on bug 1177403 from Mel Gorman

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.