> What about the new SFrame unwind info?
We're closely following up on this new format and will compare it against frame
pointers if a patch introducing a kernel unwinder for sframe is proposed and
likely to be merged. It's still very early days for SFrame though so we'll have
to see what happe
> I think it would save everyone a bit of time if we restricted the change
> to x86-64. We do not have much experience with the -mbackchain flag
> that was added at the last minute on s390x. The change owners have
> stated that they aren't interested in s390x. IBM doesn't want this.
> Platform T
I've added a new section to the proposal with the benchmark results of some
benchmarks we performed against a Fedora 37 system built with frame pointers
and a regular Fedora 37 system. The impact on most benchmarks seems limited
aside from the CPython benchmark suite (pyperformance). See the pro
Heads up that I'm trying to get https://github.com/systemd/systemd/pull/22998
in before the next systemd release which should reduce the journal size by +-
50% in a way that will be taken into account by journald's retention logic
(unlike the btrfs compression).
Also, as soon as there's a kerne
> You still might have LBR buffers deep enough for your purposes, I think
> that's worth checking. They have been around for much longer (on
> Intel).
We've been using LBR opportunistically for a while if available to augment
frame
pointer based stacks. It turns out to be quite helpful at the l
> If we can get SHSTK to work, the value of the DWARF integration and
> performance work will diminish fairly quickly because most developers
> will soon have CPUs with fairly deep (32 entry) LBR buffers, SHSTK
> support, or both.
This seems like a fairly bold assumption. I also want to add that a
> I strongly prefer the latter approach. I believe the unwinder
> executes in NMI context, meaning that it must not block and must finish
> executing in a bounded amount of time. Furthermore, any oops becomes
> an immediate kernel panic. The eBPF verifier can trivially guarantee
> that the unwi
I've just updated the proposal with an extended description describing the use
cases enabled by frame pointers in more details. More specifically, on top of
describing the profiling use case in much more detail, I've also added a
section on BPF debugging tooling, such as bcc and bpftrace, which
The proposed configuration is to add "-fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer" to the default compilation flags. Are you
alluding to inline assembly that won't have frame pointers set up correctly
even with these two options enabled?
Cheers,
Daan
__
The goal was to try and reproduce the phoronix benchmark results so this is
without any system dependencies rebuilt with frame pointers, same as the
phoronix benchmark.
Cheers,
Daan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscrib
> I have had to use frame pointers, but only for deeply embedded projects where
> the cost
> tradeoffs are different and a smaller constrained unwinder was needed.
As mentioned in the change proposal, when using sampling profilers that rely on
fast access to the stacktrace, there is currently no
Similarly, for the sysbench RAM test, which was the other test in the phoronix
benchmark showing substantial regressions when compiled with frame pointers, we
were unable to reproduce the results. Our results are as follows:
https://user-images.githubusercontent.com/9395011/177169145-d19bab77-cd
Given the recent benchmarks from Phoronix
(https://www.phoronix.com/scan.php?page=article&item=fedora-frame-pointer&num=1)
on the proposal that showed some surprising results, we went and tried to
reproduce some of the benchmarks to make sure they were actually making sense.
The first one we lo
That makes total sense. We're looking at doing exactly this. Are there any
particular benchmarks the community would be interested in? Our idea was to
take the phoronix test suite and run some of the relevant suites from that with
and without the updated packages and compare the results. On a qu
> Regressions of such magnitude can veto such changes, especially when
> they hit everyone, not just those who are highly dependent on the
> profiling tools the proposal is concerned about.
The kernel benchmarks were added as an example of openly available data we
could find on the potential impa
15 matches
Mail list logo
