https://bugzilla.suse.com/show_bug.cgi?id=1177403 https://bugzilla.suse.com/show_bug.cgi?id=1177403#c2 Mel Gorman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mgorman@suse.com --- Comment #2 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. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1177403 https://bugzilla.suse.com/show_bug.cgi?id=1177403#c4 --- Comment #4 from Michal Suchanek --- It produces only warnings and these go to /dev/null on the test builds -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1177403 https://bugzilla.suse.com/show_bug.cgi?id=1177403#c8 --- Comment #8 from Mel Gorman --- (In reply to Mel Gorman from comment #7)

(In reply to Michal Suchanek from comment #4)

...

It produces only warnings and these go to /dev/null on the test builds

So what was the final outcome here? I see it's still enabled but if the warnings are going to /dev/null, is there any point having it enabled at all?

Ok, no answer. In that case, is there an objection to disabling this option in master and SLE 15 SP3 configs? -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1177403 https://bugzilla.suse.com/show_bug.cgi?id=1177403#c10 --- Comment #10 from Mel Gorman --- (In reply to Michal Suchanek from comment #9)

It is non-trivial to make use of the warnings. There are others that we can make use of but don't currently.

I'm reading that as the "information is not used"

It would help to know what they look like, too.

Random example WARNING: vmlinux.o(.text+0x8c68): Section mismatch in reference from the variable start_here_common to the function .init.text:start_kernel() The function start_here_common() references the function __init start_kernel(). This is often because start_here_common lacks a __init annotation or the annotation of start_kernel is wrong. Mostly these are useful during development time only when adding code that uses __init annotation. This can come up during development when adding code related to hotplug which accidentally calls __init functions at runtime when the __init code has already been freed in the latter parts of boot.

However, I see enabling them in kbuild as low priority.

So are you ok if I disable them? It's an option that should be set only during development time, in production, it's useless and as the original summaries states, it affects what functions get inlined. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1177403 https://bugzilla.suse.com/show_bug.cgi?id=1177403#c12 --- Comment #12 from Mel Gorman --- (In reply to Michal Suchanek from comment #11)

So it's these warnings. I check them in the OBS logs from time to time.

On POWER the hotplug functions change all the time :/

I could adjust the script to pick them out from OBS logs. Getting them from the kbuild test results is not trivial ATM.

So given that this has a runtime impact due to functions not being inlined that *should* be inlined, is it worth enabling it in production? The ideal really would be that this is checked as a debugging step and warned on merging to a for-next branch if new section warnings shows up instead of having a runtime impact. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1177403 https://bugzilla.suse.com/show_bug.cgi?id=1177403#c14 Mel Gorman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Mel Gorman --- (In reply to Michal Suchanek from comment #13)

Ok, let's drop it, and add the config in kbuild tests once they can extract the warnings.

Thanks. I pushed the change to master and SLE 15 SP3. master has already been updated and SLE 15 SP3 will get updated eventually so I think we can close this now! -- You are receiving this mail because: You are on the CC list for the bug.