4 ms·

The article points out that the kernel uses ORC instead of DWARF for unwinding. I wonder if that could ever become an option in userspace? I imagine that if all

The article points out that the kernel uses ORC instead of DWARF for unwinding. I wonder if that could ever become an option in userspace? I imagine that if all you’re interested in is stack traces, instead of debugging (which DWARF is designed for), ORC would be a very nice performance win. And it’s not as if they’re mutually exclusive, either: there’s no reason why a binary or debuginfo couldn’t just ship both. In any case, the runtime performance hit of frame pointers is quite high, and since we do have things like DWARF (and maybe ORC someday?), I’d still argue that frame pointers aren’t necessary. It’s nice to have that extra register free!

amluto 4y ago
Native ORC generation from GCC or LLVM or userspace tooling like objtool would be nifty. FWIW, ORC was specifically designed to be efficient, but it was not designed to be future-proof against complex toolchain changes. Since all the ORC tooling is in the kernel, it can evolve together if needed. (I was a bit involved in the design — I helped optimize the format to reduce cache misses on lookup.)
the_mitsuhiko 4y ago
> In any case, the runtime performance hit of frame pointers is quite high That's not true at all. It's in some very rare cases. Firefox I think at this point ships with framepointers enabled and so does every M1/M2 mac app and all iOS applications as it's mandatory for the calling convention on Apple.
- remexre 4y ago
  On AArch64 I think it's cheaper because losing one register doesn't hurt as much, since you've got twice as many.
  - yvdriess 4y ago
    nitpick: it's the number of physical registers that matter more here, not ISA registers
    - remexre 4y ago
      Why wouldn't the lower ISA register count lead to more spills, regardless of the physical count? Is store forwarding really that effective?
      - gpderetta 4y ago
        It isn't.
- nneonneo 4y ago
  The ORC documentation [1] cites a 5-10% perf hit [2] on x86. Now, granted, we're talking about an architecture that has only 8 logical registers to begin with, so losing one is going to hurt a lot more than x86-64 (16 logical registers) or AARCH64 (32 logical registers). But, 5-10% is definitely a noticeable perf hit. Phoronix [3] did a test of "-fno-omit-frame-pointer" during the discussion on whether to enable the flag for Fedora, this time on x86-64. They found an average 14% performance hit on a wide variety of benchmarks. [1] https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html [2] https://lore.kernel.org/all/20170602104048.jkkzssljsompjdwy@suse.de/ https://lore.kernel.org/all/20170602104048.jkkzssljsompjdwy@... [3] https://www.phoronix.com/review/fedora-frame-pointer/5 https://www.phoronix.com/review/fedora-frame-pointer/5
  - zznzz 4y ago
    See also https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QNCVIZCVSJ4M7ILCBPP23R77QE4YLASO/ https://lists.fedoraproject.org/archives/list/devel@lists.fe... - the botan phoronix results with frame pointers were probably measuring debug builds.
tdullien 4y ago
For prodfiler.com we convert .eh_frame (DWARF) unwinding format to something that is more similar to ORC and optimized for lookup in eBPF data structures.

amluto 4y ago

Native ORC generation from GCC or LLVM or userspace tooling like objtool would be nifty. FWIW, ORC was specifically designed to be efficient, but it was not designed to be future-proof against complex toolchain changes. Since all the ORC tooling is in the kernel, it can evolve together if needed. (I was a bit involved in the design — I helped optimize the format to reduce cache misses on lookup.)

the_mitsuhiko 4y ago

> In any case, the runtime performance hit of frame pointers is quite high That's not true at all. It's in some very rare cases. Firefox I think at this point ships with framepointers enabled and so does every M1/M2 mac app and all iOS applications as it's mandatory for the calling convention on Apple.

remexre 4y ago
On AArch64 I think it's cheaper because losing one register doesn't hurt as much, since you've got twice as many.
- yvdriess 4y ago
  nitpick: it's the number of physical registers that matter more here, not ISA registers
  - remexre 4y ago
    Why wouldn't the lower ISA register count lead to more spills, regardless of the physical count? Is store forwarding really that effective?
    - gpderetta 4y ago
      It isn't.
nneonneo 4y ago
The ORC documentation [1] cites a 5-10% perf hit [2] on x86. Now, granted, we're talking about an architecture that has only 8 logical registers to begin with, so losing one is going to hurt a lot more than x86-64 (16 logical registers) or AARCH64 (32 logical registers). But, 5-10% is definitely a noticeable perf hit. Phoronix [3] did a test of "-fno-omit-frame-pointer" during the discussion on whether to enable the flag for Fedora, this time on x86-64. They found an average 14% performance hit on a wide variety of benchmarks. [1] https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html [2] https://lore.kernel.org/all/20170602104048.jkkzssljsompjdwy@suse.de/ https://lore.kernel.org/all/20170602104048.jkkzssljsompjdwy@... [3] https://www.phoronix.com/review/fedora-frame-pointer/5 https://www.phoronix.com/review/fedora-frame-pointer/5
- zznzz 4y ago
  See also https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QNCVIZCVSJ4M7ILCBPP23R77QE4YLASO/ https://lists.fedoraproject.org/archives/list/devel@lists.fe... - the botan phoronix results with frame pointers were probably measuring debug builds.

tdullien 4y ago

For prodfiler.com we convert .eh_frame (DWARF) unwinding format to something that is more similar to ORC and optimized for lookup in eBPF data structures.