On Tue Nov 29, 2022 at 12:57 CST, Jeremy Linton wrote:
> Hi,
>
>
> On 6/16/22 15:53, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer
> >
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in
On 29/11/2022 19:57, Jeremy Linton wrote:
Why not turn this on just for rawhide and leave it off for the main
distro releases?
Mass rebuild is a huge pain for maintainers due to FTBFS issues, and
doing it multiple times is unacceptable.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
Hi,
On 6/16/22 15:53, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if
On 11/22/22 10:19, Florian Weimer wrote:
> * Neal Gompa:
>
>> On Tue, Nov 22, 2022 at 6:54 AM Florian Weimer wrote:
>>>
>>> Why isn't this something that is up to the toolchain team to decide?
>>>
>>
>> The toolchain team doesn't work with the full corpus of packages,
>> doesn't really interface
* Neal Gompa:
> On Tue, Nov 22, 2022 at 6:54 AM Florian Weimer wrote:
>>
>> Why isn't this something that is up to the toolchain team to decide?
>>
>
> The toolchain team doesn't work with the full corpus of packages,
> doesn't really interface with most of the packagers, and doesn't work
> with
On Tue, Nov 22, 2022 at 6:54 AM Florian Weimer wrote:
>
> Why isn't this something that is up to the toolchain team to decide?
>
The toolchain team doesn't work with the full corpus of packages,
doesn't really interface with most of the packagers, and doesn't work
with most of the upstreams that
Why isn't this something that is up to the toolchain team to decide?
What makes FESCo more qualified than the toolchain maintainers to
determine the best approach for Fedora?
Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To
> > what is the impact of the proposed change on non-x86 platforms? I
> > assume the proposal focuses on x86, but the distro wide flags are shared
> > across all platforms in Fedora, it means aarch64, ppc64le and s390x.
> > With RISC-V waiting behind the door ...
>
> None, because this proposal is
On 11/10/22 08:59, Michael Catanzaro wrote:
> On Wed, Nov 9 2022 at 09:39:04 AM +0100, Vitaly Zaitsev via devel
> wrote:
>> According to tests, this will slow down your system to 2.5%+, which is
>> unacceptable for a general purpose distribution.
>
> Of course, without the frame pointers,
On Wed, Nov 09, 2022 at 04:26:23AM +, Naheem Zaffar wrote:
> On Tue, 8 Nov 2022, 19:22 Vitaly Zaitsev via devel, <
> devel@lists.fedoraproject.org> wrote:
>
> > On 08/11/2022 19:53, Naheem Zaffar wrote:
> > > Has there been any consideration to turn on frame pointers for atleast
> > > dev
On 10/11/2022 14:59, Michael Catanzaro wrote:
Of course, without the frame pointers, profiling software is impossible
and performance engineers are unable to investigate performance problems
using Fedora.
99.999% shouldn't suffer because of 0.001%.
--
Sincerely,
Vitaly Zaitsev
On Thu, Nov 10, 2022 at 9:00 AM Michael Catanzaro wrote:
>
> On Wed, Nov 9 2022 at 09:39:04 AM +0100, Vitaly Zaitsev via devel
> wrote:
> > According to tests, this will slow down your system to 2.5%+, which is
> > unacceptable for a general purpose distribution.
>
> Of course, without the frame
On Wed, Nov 9 2022 at 09:39:04 AM +0100, Vitaly Zaitsev via devel
wrote:
According to tests, this will slow down your system to 2.5%+, which is
unacceptable for a general purpose distribution.
Of course, without the frame pointers, profiling software is impossible
and performance engineers
On Wed, 2022-11-09 at 19:27 -0500, Demi Marie Obenour wrote:
> On 11/9/22 05:21, Dan Horák wrote:
> > On Tue, 01 Nov 2022 11:26:13 -
> > Daan De Meyer via devel wrote:
> >
> > > I've added a new section to the proposal with the benchmark
> > > results of some benchmarks we performed against
On 11/9/22 05:21, Dan Horák wrote:
> On Tue, 01 Nov 2022 11:26:13 -
> Daan De Meyer via devel wrote:
>
>> 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
* Demi Marie Obenour:
> On 11/8/22 18:46, Frank Ch. Eigler wrote:
>> Demi Marie Obenour writes:
>>
>>> Three other options I can think of:
>>> [...]
>>
>> Another one:
>>
>> 4. Speed up out-of-context backtracer(s), possibly consuming
>> kernel-perf-ringbuffer stack dumps, or possibly
On Tue, 01 Nov 2022 11:26:13 -
Daan De Meyer via devel wrote:
> 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
On Wed, Nov 09, 2022 at 04:26:23AM +, Naheem Zaffar wrote:
> On Tue, 8 Nov 2022, 19:22 Vitaly Zaitsev via devel, <
> devel@lists.fedoraproject.org> wrote:
>
> > On 08/11/2022 19:53, Naheem Zaffar wrote:
> > > Has there been any consideration to turn on frame pointers for atleast
> > > dev
On 09/11/2022 05:26, Naheem Zaffar wrote:
Not all builds in rawhide are release builds. You will get for instance
the whole gnome stack beta releases and rc releases during development.
To achieve the goal, you must rebuild every single package in a
dependency tree, including such important
On Tue, 8 Nov 2022, 19:22 Vitaly Zaitsev via devel, <
devel@lists.fedoraproject.org> wrote:
> On 08/11/2022 19:53, Naheem Zaffar wrote:
> > Has there been any consideration to turn on frame pointers for atleast
> > dev releases?
>
>
> Fedora has no dev releases. Mass rebuild is a huge pain for
On 11/8/22 18:46, Frank Ch. Eigler wrote:
> Demi Marie Obenour writes:
>
>> Three other options I can think of:
>> [...]
>
> Another one:
>
> 4. Speed up out-of-context backtracer(s), possibly consuming
> kernel-perf-ringbuffer stack dumps, or possibly using another
> event source
Demi Marie Obenour writes:
> Three other options I can think of:
> [...]
Another one:
4. Speed up out-of-context backtracer(s), possibly consuming
kernel-perf-ringbuffer stack dumps, or possibly using another
event source to trigger and work via ptrace and /proc/$pid/mem
- FChE
On 08/11/2022 19:53, Naheem Zaffar wrote:
Has there been any consideration to turn on frame pointers for atleast
dev releases?
Fedora has no dev releases. Mass rebuild is a huge pain for maintainers
due to FTBFS issues, and doing it multiple times is unacceptable.
If someone needs extended
On Tue, Nov 08, 2022 at 06:53:46PM +, Naheem Zaffar wrote:
> Has there been any consideration to turn on frame pointers for atleast dev
> releases?
>
> AFAIK the kernel already has a separate configuration during the
> development phase of the distro-cycle
This practice already causes
Has there been any consideration to turn on frame pointers for atleast dev
releases?
AFAIK the kernel already has a separate configuration during the
development phase of the distro-cycle
Can this be extended for rebuilds of alpha and beta releases in rawhide to
turn on frame pointers as an
On 11/7/22 09:59, Daniel Alley wrote:
> The references of the proposal has some discussion on this subject.
> Basically, this was already considered and rejected by the kernel
> developers including Torvalds directly on the basis that DWARF
> unwinding support is simply too complex and
> On 11/1/22 07:38, Dominique Martinet wrote:
>
> Has adding kernel support for DWARF unwinding been considered instead?
The references of the proposal has some discussion on this subject. Basically,
this was already considered and rejected by the kernel developers including
Torvalds directly
On 11/1/22 07:38, Dominique Martinet wrote:
> Daan De Meyer via devel wrote on Tue, Nov 01, 2022 at 11:26:13AM -:
>> 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
Daan De Meyer via devel wrote on Tue, Nov 01, 2022 at 11:26:13AM -:
> 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
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
It's not even a question worth asking because it's both impractical and
unlikely to actually fix the situation we have.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora
On So, 2022-07-10 at 10:36 -0700, Gordon Messmer wrote:
> On 7/10/22 04:38, Vitaly Zaitsev via devel wrote:
> > Have you rebuilt all system packages with -fno-omit-frame-pointer or
> > just tested packages?
>
>
> No. Early in the thread, Tomasz Torcz posted a link to a Phoronix
> article as
> Unfortunately, no, there's no in-kernel DWARF unwinder due to the complexity
> involved.
> Instead, the kernel uses ORC and has an unwinder for that. Adding ORC support
> to all of
> Linux userspace so that we can unwind it in the kernel isn't likely to
> happen, since
> all tooling would
> My comment was specifically about sysprof. I've been told that the
> GNOME developers will not even consider anything else. This means that
> we need to fix sysprof. If we do that, it will be possible to use GNOME
> OS for profiling on older CPUs, and hardware-assisted backtraces on
> newer
> 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
* Daan De Meyer via devel:
>> 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
ware support.
Cheers,
Daan
From: Florian Weimer
Sent: 11 July 2022 07:12
To: Matthias Clasen
Cc: Development discussions related to Fedora
Subject: Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation
flags (System-Wide Change proposal)
* Mat
* Matthias Clasen:
> On Wed, Jul 6, 2022 at 3:06 PM Florian Weimer wrote:
>
>> If the GNOME's sysprof does not work with Fedora, fix it or use
>> something else. Do not change how Fedora is built.
>
> The result of that attitude is that performance work in the desktop
> space is happening on
* Demi Marie Obenour:
> That is the problem right here: .eh_frame-based unwinding is too slow,
> so it has to be done offline in userspace. What about instead adding
> ORC information to userspace? That would be much faster to use.
I'm not sure ORC covers all the registers that could be used
* Fabio Valentini:
> On Fri, Jul 8, 2022 at 9:20 PM Christian Hergert wrote:
>>
>> > So it looks like what you folks are doing is actually very similar to what
>> > Facebook is doing. That is interesting, and explains why some GNOME
>> > developers are jumping on the bandwagon of this Change
On 7/10/2022 11:36 AM, Gordon Messmer wrote:
On 7/10/22 04:38, Vitaly Zaitsev via devel wrote:
Have you rebuilt all system packages with -fno-omit-frame-pointer or
just tested packages?
No. Early in the thread, Tomasz Torcz posted a link to a Phoronix
article as evidence that Fedora's
On 7/10/22 10:55, Vitaly Zaitsev via devel wrote:
On 10/07/2022 19:36, Gordon Messmer wrote:
No. Early in the thread, Tomasz Torcz posted a link to a Phoronix
article as evidence that Fedora's performance was behind other
distributions.
All packages in the dependency tree must be rebuilt
On 10/07/2022 19:36, Gordon Messmer wrote:
No. Early in the thread, Tomasz Torcz posted a link to a Phoronix
article as evidence that Fedora's performance was behind other
distributions.
All packages in the dependency tree must be rebuilt with
-fno-omit-frame-pointer flag, otherwise the
On 7/10/22 04:38, Vitaly Zaitsev via devel wrote:
Have you rebuilt all system packages with -fno-omit-frame-pointer or
just tested packages?
No. Early in the thread, Tomasz Torcz posted a link to a Phoronix
article as evidence that Fedora's performance was behind other
distributions. At
On 7/9/22 12:05, Christian Hergert wrote:
>> Why does the unwinding need to happen in the kernel? The kernel can
>> already asynchronously invoke userspace code in the form of signal
>> handlers. Is the problem that it is necessary to collect profiling
>> information in the middle of a system
On Sunday, July 10, 2022, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:
> drago01 wrote:
>
> > On Sunday, July 10, 2022, Kevin Kofler via devel <
> > devel@lists.fedoraproject.org> wrote:
> >
> >> drago01 wrote:
> >> > One thing which seems to be completely missing in the
drago01 wrote:
> On Sunday, July 10, 2022, Kevin Kofler via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> drago01 wrote:
>> > One thing which seems to be completely missing in the conversation is
>> > how this affects battery life. Having lower performance, means the CPU
>> > has to do
On Sunday, July 10, 2022, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:
> drago01 wrote:
> > One thing which seems to be completely missing in the conversation is how
> > this affects battery life. Having lower performance, means the CPU has to
> > do more work / be in a higher
On 09/07/2022 22:32, Gordon Messmer wrote:
I cannot replicate any of the differences that I would expect to be able
to. More than anything else, their results look like evidence of a bug
in the Xeon Platinum 8380.
Have you rebuilt all system packages with -fno-omit-frame-pointer or
just
drago01 wrote:
> One thing which seems to be completely missing in the conversation is how
> this affects battery life. Having lower performance, means the CPU has to
> do more work / be in a higher power state for a longer time frame.
Who in their right mind does CPU profiling on battery?
One thing which seems to be completely missing in the conversation is how
this affects battery life. Having lower performance, means the CPU has to
do more work / be in a higher power state for a longer time frame.
___
devel mailing list --
Demi Marie Obenour
Sent: 09 July 2022 04:02
To: devel@lists.fedoraproject.org
Subject: Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation
flags (System-Wide Change proposal)
On 7/8/22 20:18, Christian Hergert wrote:
>> That is the problem right here: .eh_frame-based un
On 6/21/22 21:40, Gordon Messmer wrote:
On 6/21/22 13:10, Matthew Miller wrote:
Phoronix credits this to those distros shipping with P-state
Performance by default.
Yes, but I doubt that for several reasons: First, it's a claim without
evidence. That setting isn't the only difference
> Why does the unwinding need to happen in the kernel? The kernel can
> already asynchronously invoke userspace code in the form of signal
> handlers. Is the problem that it is necessary to collect profiling
> information in the middle of a system call, where another syscall
> would see
On 7/8/22 20:18, Christian Hergert wrote:
>> That is the problem right here: .eh_frame-based unwinding is too slow, so it
>> has to be
>> done offline in userspace. What about instead adding ORC information to
>> userspace? That
>> would be much faster to use.
>
> I'm not familiar with ORC,
> That is the problem right here: .eh_frame-based unwinding is too slow, so it
> has to be
> done offline in userspace. What about instead adding ORC information to
> userspace? That
> would be much faster to use.
I'm not familiar with ORC, but there are a few things that initially come to
On 7/8/22 15:29, Christian Hergert wrote:
>> Frank Ch. Eigler mentions that elfutils has a more modern unwinding library.
>> Could that perhaps solve your performance issues with libunwind?
>
> I don't think so. The problem is two-fold.
>
> First, we have to capture enough of the stack to do
On Fri, Jul 8, 2022 at 9:20 PM Christian Hergert wrote:
>
> > So it looks like what you folks are doing is actually very similar to what
> > Facebook is doing. That is interesting, and explains why some GNOME
> > developers are jumping on the bandwagon of this Change proposal.
>
> To be fair,
> Frank Ch. Eigler mentions that elfutils has a more modern unwinding library.
> Could that perhaps solve your performance issues with libunwind?
I don't think so. The problem is two-fold.
First, we have to capture enough of the stack to do offline unwinding. I think
the default many people do
> So it looks like what you folks are doing is actually very similar to what
> Facebook is doing. That is interesting, and explains why some GNOME
> developers are jumping on the bandwagon of this Change proposal.
To be fair, we've been complaining about it internally in GNOME for probably
I don’t think we should be gatekeeping who can propose or discuss a
Change. I do think that the opinions of the upstream and downstream GCC
maintainers should be weighed quite heavily when considering a change to
the default compiler flags.
As a FESCo member, I’m waiting to see if the Change
On 7/7/22 16:13, Christian Hergert wrote:
> Sysprof has modular data collection backends, and not everything requires
> linking against libunwind.
>
> For those not familiar with Sysprof, or profiling the desktop at large,
> generally a single program is not the problem. The performance
Theodore Papadopoulo wrote:
> gdb and similar tools are confused, notably because local variables are
> "optimsed out" (which I suspect is related to frame pointer).
It is not.
This is related to compiling with any optimization at all, and you
definitely do not want production binaries compiled
On Thu, Jul 07, 2022 at 08:13:52PM -, Christian Hergert wrote:
> Sysprof has modular data collection backends, and not everything
> requires linking against libunwind.
>
> For those not familiar with Sysprof, or profiling the desktop at
> large, generally a single program is not the problem.
PS: One more question:
Christian Hergert wrote:
> We have an in-tree parser for ELF that allows us to avoid a lot of
> extraneous code when extracting symbols. Partially because libunwind is
> incredibly slow (by profiler requirements), and partially because
> historically we never had to stash
Christian Hergert wrote:
> For those not familiar with Sysprof, or profiling the desktop at large,
> generally a single program is not the problem. The performance problems
> often exist across a number of processes.
[…]
> The most used collector, however, is the perf collector which is just
>
On 7/6/22 08:30, Vitaly Zaitsev via devel wrote:
On 05/07/2022 21:15, Matthias Clasen wrote:
And I doubt that you'd be able to notice a 'smaller than 1% slowdown'
on your system.
4% slowdown is unacceptable.
At least for Fedora Workstation, being
a useful system for developers with working
On 7/7/22 10:46, Frank Ch. Eigler wrote:
>
> ngompa13 wrote:
>
>> [...]
>> I agree, this is a completely unacceptable statement to make. The
>> problem isn't sysprof, the problem is that profiling is garbage on
>> Linux by default.
>
> That's an overstatement.
>
>> And while maybe most
On Tue, Jul 5 2022 at 01:42:05 PM +0200, Fabio Valentini
wrote:
No - I think the problem is that adding those flags to the default
build configuration will affect the whole system - all executables and
shared libraries, not only "leaf" binaries. And that makes your
benchmarks (and those run by
Sysprof has modular data collection backends, and not everything requires
linking against libunwind.
For those not familiar with Sysprof, or profiling the desktop at large,
generally a single program is not the problem. The performance problems often
exist across a number of processes. That
ngompa13 wrote:
> [...]
> I agree, this is a completely unacceptable statement to make. The
> problem isn't sysprof, the problem is that profiling is garbage on
> Linux by default.
That's an overstatement.
> And while maybe most developers may not bother to do profiling right
> now, we don't
On Thu, Jul 7, 2022 at 7:43 AM Matthias Clasen wrote:
>
>
>
> On Wed, Jul 6, 2022 at 3:06 PM Florian Weimer wrote:
>
>>
>> If the GNOME's sysprof does not
>> work with Fedora, fix it or use something else. Do not change how
>> Fedora is built.
>
>
> The result of that attitude is that
On Wed, Jul 6, 2022 at 3:06 PM Florian Weimer wrote:
> If the GNOME's sysprof does not
> work with Fedora, fix it or use something else. Do not change how
> Fedora is built.
>
The result of that attitude is that performance work in the desktop space
is happening
on GNOME OS images, or in
Michael Catanzaro writes:
> I can point you to documentation for sysprof:
> https://gitlab.gnome.org/GNOME/sysprof#debugging-symbols
> which says that every library should be built with
> -fno-omit-frame-pointer.
Given that sysprof is a userspace program, it's not in a giant rush, so
it should
On 7/6/2022 1:05 PM, Florian Weimer wrote:
* Michael Catanzaro:
On Wed, Jul 6 2022 at 08:06:45 AM -0600, Jeff Law
wrote:
If I'm understanding things correctly, the original proposal is trying
to make a very special case of profiling work better -- a case that
99.9% of Fedora users do not
Michael Catanzaro wrote:
> I can point you to documentation for sysprof:
>
> https://gitlab.gnome.org/GNOME/sysprof#debugging-symbols
>
> which says that every library should be built with
> -fno-omit-frame-pointer.
And why is that? Do they not use libunwind, or GDB, or any other sane
Michael Catanzaro wrote:
> Problem is that in order to get good profiling results today, you need
> to rebuild all dependencies with frame pointers enabled. And that is
> not realistic. Nobody does that.
Actually, the Facebook developers, the ones who are proposing this very
Change, claim that
Marek Polacek wrote:
> On Tue, Jul 05, 2022 at 03:47:26PM -0400, Matthias Clasen wrote:
>> (Un)acceptable for whom?
>
> GCC maintainers in Fedora, at least.
What I do not understand is why a Change that wants to change the default
GCC flags is even under discussion at all without the buy-in
Dan Čermák wrote:
> Please never run ASAN in production workloads:
> https://www.openwall.com/lists/oss-security/2016/02/17/9
>
> tl;dr; you'll create a local root exploit.
Oh, the joys of automagically added insecure environment variable handlers…
Good to know!
Kevin Kofler
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
* Michael Catanzaro:
> On Wed, Jul 6 2022 at 08:06:45 AM -0600, Jeff Law
> wrote:
>> If I'm understanding things correctly, the original proposal is trying
>> to make a very special case of profiling work better -- a case that
>> 99.9% of Fedora users do not need or care about.That seems
* Jeff Law:
> If I'm understanding things correctly, the original proposal is trying
> to make a very special case of profiling work better -- a case that
> 99.9% of Fedora users do not need or care about. That seems like a
> particularly bad cost/benefit for this proposal.
It became clear
On Wed, Jul 6 2022 at 10:05:17 AM -0700, Tom Stellard
wrote:
With the current profiling methods, are you able to at least narrow
down which libraries
applications spend the most time in? Or do you really need detailed
profile information for
every single library in order to determine where
On 7/6/22 08:42, Michael Catanzaro wrote:
On Wed, Jul 6 2022 at 04:20:50 PM +0100, Jonathan Wakely
wrote:
You build locally and profile using your locally built packages.
Problem is that in order to get good profiling results today, you need to
rebuild all dependencies with frame pointers
On 7/6/22 08:20, Jonathan Wakely wrote:
On Wed, 6 Jul 2022 at 15:57, Jeff Law wrote:
On 7/6/2022 8:20 AM, Michael Catanzaro wrote:
On Wed, Jul 6 2022 at 08:06:45 AM -0600, Jeff Law
wrote:
If I'm understanding things correctly, the original proposal is trying
to make a very special case
On Wed, Jul 6 2022 at 04:20:50 PM +0100, Jonathan Wakely
wrote:
You build locally and profile using your locally built packages.
Problem is that in order to get good profiling results today, you need
to rebuild all dependencies with frame pointers enabled. And that is
not realistic. Nobody
On Wed, 6 Jul 2022 at 15:57, Jeff Law wrote:
>
>
>
> On 7/6/2022 8:20 AM, Michael Catanzaro wrote:
> > On Wed, Jul 6 2022 at 08:06:45 AM -0600, Jeff Law
> > wrote:
> >> If I'm understanding things correctly, the original proposal is trying
> >> to make a very special case of profiling work
On 06/07/2022 16:20, Michael Catanzaro wrote:
But all Fedora users benefit from performance improvements implemented
as a result of profiling.
I don't think so. Only the proposal owners will get benefit.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On 7/6/2022 8:20 AM, Michael Catanzaro wrote:
On Wed, Jul 6 2022 at 08:06:45 AM -0600, Jeff Law
wrote:
If I'm understanding things correctly, the original proposal is trying
to make a very special case of profiling work better -- a case that
99.9% of Fedora users do not need or care about.
On Wed, Jul 6 2022 at 08:06:45 AM -0600, Jeff Law
wrote:
If I'm understanding things correctly, the original proposal is trying
to make a very special case of profiling work better -- a case that
99.9% of Fedora users do not need or care about.That seems like a
particularly bad cost/benefit
On Wed, Jul 6 2022 at 09:26:44 AM -0400, Marek Polacek
wrote:
I think you may be underestimating how much even 1% matters.
For Fedora Workstation, the primary concern should be to make sure
sysprof works nicely. That's our profiling tool, and it currently
doesn't work well at all with
On 7/6/2022 7:26 AM, Marek Polacek wrote:
On Tue, Jul 05, 2022 at 03:47:26PM -0400, Matthias Clasen wrote:
On Tue, Jul 5, 2022 at 3:40 PM Marek Polacek wrote:
Maybe not, but even ~1% is still an unacceptable slowdown. It would take
about a year for the compiler to catch up.
On Tue, Jul 05, 2022 at 03:47:26PM -0400, Matthias Clasen wrote:
> On Tue, Jul 5, 2022 at 3:40 PM Marek Polacek wrote:
>
> >
> > Maybe not, but even ~1% is still an unacceptable slowdown. It would take
> > about a year for the compiler to catch up.
> >
> >
> (Un)acceptable for whom?
GCC
Kevin Kofler via devel writes:
> Fabio Valentini wrote:
>> And if we say this argument is valid, then should we also build all our
>> packages with ASAN / TSAN / etc. instrumentation, as well?
>
> And ASAN would actually have tangible benefits for end users, namely
> preventing some memory bug
On 05/07/2022 21:15, Matthias Clasen wrote:
And I doubt that you'd be able to notice a 'smaller than 1% slowdown' on
your system.
4% slowdown is unacceptable.
At least for Fedora Workstation, being
a useful system for developers with working debugging and profiling tools
should have some
Fabio Valentini wrote:
> And if we say this argument is valid, then should we also build all our
> packages with ASAN / TSAN / etc. instrumentation, as well?
And ASAN would actually have tangible benefits for end users, namely
preventing some memory bug exploits, whereas frame pointers only slow
* Matthias Clasen:
> not to mention hardware continuously getting faster too...
The proposal is about enabling this feature for older hardware. Recent
x86-64 CPUs can maintain an array of return addresses in hardware (so
basically the backtrace is available directly). Kernel patches to
enable
On Tue, Jul 5, 2022 at 9:16 PM Matthias Clasen wrote:
>
> On Thu, Jun 30, 2022 at 4:55 AM Kevin Kofler via devel
> wrote:
>>
>> Daan De Meyer via devel wrote:
>> > Which shows a smaller than 1% slowdown between the binary built with frame
>> > pointers and the binary built without frame
On Tue, Jul 5, 2022 at 3:40 PM Marek Polacek wrote:
>
> Maybe not, but even ~1% is still an unacceptable slowdown. It would take
> about a year for the compiler to catch up.
>
>
(Un)acceptable for whom? And why would it be unacceptable?
You just said compilers will make up for it quickly, not
On Tue, Jul 05, 2022 at 03:15:02PM -0400, Matthias Clasen wrote:
> On Thu, Jun 30, 2022 at 4:55 AM Kevin Kofler via devel <
> devel@lists.fedoraproject.org> wrote:
>
> > Daan De Meyer via devel wrote:
> > > Which shows a smaller than 1% slowdown between the binary built with
> > frame
> > >
1 - 100 of 151 matches
Mail list logo
