On Wed, Nov 27, 2024 at 5:08 PM Aaron Puchert <aaronpuchert@alice-dsl.net> wrote:
Am 27.11.24 um 04:42 schrieb Andrii Nakryiko:
On Tue, Nov 26, 2024 at 6:43 PM Aaron Puchert <aaronpuchert@alice-dsl.net> wrote:
Am 25.11.24 um 23:59 schrieb Andrii Nakryiko:
[...] DWARF's .eh_frame-based stack unwinding tables. The latter is actually doesn't land itself well to system-wide profiling, and involved compromises in memory usage, CPU usage, and just plain reliability (no one will guarantee you that you captured all of the stack, for example). The first two arguments are problematic: remember that we're talking about frame pointers, which cost CPU for all users. On one hand you're But how much CPU does it actually cost? You can see 1-2% in *benchmarks*,
Sure, that was my understanding. But 1% across everything is not a small
My whole point was that *benchmark* results are just part of the story, and we can't just take 1% and use that as "this is how much slower everything will be". And yet, you go ahead and do exactly that, doing some hypothetical math about collective slowdowns, with average usage costs, etc. I'm sorry, I see this as a completely useless hypothetical exercise. On the other hand, you completely discount and doubt any improvements enabled by more readily available profiling and observability tooling, even though it was *already* shown both in server-side land (e.g., in Meta fleet) and in Fedora distro ecosystem.
regression. I know you're arguing that lots of tools don't even support DWARF unwinding, but let's just focus on those that do: even if 2% of users does profiling, and the overhead is 20%, we have an average CPU usage cost of 0.4% for DWARF, which is still below 1%. (That's assuming those users are profiling all the time.) So total CPU usage across all users is going to go up if we enable FP.
And it's not given at all that we get benefits of the same order. In individual programs we can certainly get much more, but across all workloads I doubt it. Most CPU-intensive applications are already subject to heavy profiling.
From the Fedora Proposal:
Compiling the kernel with GCC is 2.4% slower with frame pointers That's quite a bit for a compiler. The LLVM compile-time tracker [1] shows "instructions" instead of "cycles" per default because the latter is too noisy for the regressions that we're interested in, which is basically everything >0.5%. Given that I've spend time on trying to get some 0.5% improvements, I'm not sure that I'm willing to accept a 2.4% regression. But if we enable frame pointers globally and I disable them in LLVM, I make other people mad.
there is no perceptible CPU overhead associated with that.
Not perceptible yes, because it's rather equitably distributed. But in terms of total cost it's much more significant than most perceptible regressions.
In server land calculating and comparing these total costs seems a bit more reasonable (even though, world and life is too complicated to just do such simple math). And there it was shown many times over that frame pointers enabled way more cost savings than any initial costs. For non-server use cases, IMO, what matters is whether the user experiences noticeable degradation in the short term (with the eye towards medium-to-long term benefits to the ecosystem in general). And if kernel compilation takes a second longer, I don't see it as a big deal. But I'll leave it to the openSUSE community to argue these numbers. I tried to clarify upsides and downsides of both FR and .eh_frame-based unwinding, which I believe I did. Convincing anyone about what is an acceptable cost of enabling frame pointers is not something I want to do.
I've said this in the beginning: I'm not against frame pointers, but I don't like how quickly we're willing to wave away the cost and acceptability of out-of-band alternatives.
There is nothing "quickly" here. The Fedora conversation was long and drawn out. Pro-FP folks prevailed, ultimately. We don't seem to be regretting this. OpenSUSE is just asked to not fall behind, and are certainly not pioneers here (no offense and disrespect intended).