> From: Sam James <s...@gentoo.org> > Date: Mon, 18 Sep 2023 08:21:45 +0100
> Hans-Peter Nilsson <h...@axis.com> writes: > > >> From: Sam James <s...@gentoo.org> > >> Date: Sun, 17 Sep 2023 05:00:37 +0100 > > > >> Hans-Peter Nilsson via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > >> > The situation was described as "we noticed that some test > >> > suites takes 35% percent longer time to finish. After > >> > further investigation it was noticed that running systemctl > >> > unmask x takes around 5s more time on [version including > >> > patch vs. before that patch]" (timing out some tests). > >> > Reverting that patch fixed the drop in performance. > >> > >> Did some bug ever get filed for this to see if we can do a bit > >> better here? > > > > Not that I know of; neither for systemd nor gcc. > > > >> Some slowdown doesn't mean it's of the expected magnitude. > > > > Can you please rephrase that? > > Sorry, what I meant was: yes, I'd expect a bit of a slowdown > with this option that's unavoidable, but what you're describing > sounds far beyond the normal case. Thanks. My take is that it's something I more or less expect when indiscriminately using that option. IOW, for code consciously using that option, a step is necessary where the code is vetted and adjusted, for example to remove large structures and arrays allocated on the stack (just a guess). > (to the extent that it might be > we're either missing an optimisation in GCC for the relevant bits, > or the systemd parts being exercised here are pathological.) Sorry, I don't have anything more in terms of local observations from that investigation; no perf and flamegraphs. Again as above, the issue should be observable as a noticeable slowdown for "systemctl unmask x" for a systemd compiled with/without 1a4e392760. brgds, H-P
