Tumbleweed - Review of the week 2022/19
Dear Tumbleweed users and hackers, This week you ‘only’ had to update your machine 5 times – for the snapshots 0505, which was for some reason not announced, 0506, 0507, 0509, and 0510 (the last one fresh off the press). 0508 would have been ok, but QA was slightly slower than OBS and so the new snapshot moved to QA before the old one was completely tested. Oops. Anyway, nothing was lost, all good things from that snapshot are still shipped, just a day later. So, what did those 5 snapshots bring you? The most interesting changes include: * Mesa 22.0.3 * Mozilla Firefox 100.0 * KDE Plasma 5.24.5 * Meson 0.62 * gpg 2.3.6: Up to five times faster verification of detached signatures * Linux kernel 5.17.5 * gnome-shell & mutter 42.1 (late arrivals to the GNOME 42.1 update) * Poppler 22.05.0 * Virtualbox 6.1.34 * GCC 12.1 – with snapshot 0510, gcc12 has become the distro default compiler. All packages have been attempted to be rebuilt. This also means that the recently enabled FullRelRo support (-z now) is enabled across the board. There are currently about 370 build failures reported in openSUSE:Factory (non-ring packages) * systemd 250.5 This makes for quite an impressive list in just one week. Granted, a few of those things had been in staging areas for a while (days to weeks). And as you’re already used to, this is no reason to stop. Au contraire: the stagings are already filled again with the following presents: * KDE Gear 22.04.1 * Attempting to build the distro using FORTIFY_SOURCE=3 instead of FORTIFY_SOURCE=2 * Linux kernel 5.17.7 * GStreamer 1.20.2 * Perl 5.34.1 * Python 3.10 as the default interpreter Cheers, Dominique
Il 13/05/22 10:19, Dominique Leuenberger / DimStar ha scritto:
Dear Tumbleweed users and hackers,
This week you ‘only’ had to update your machine 5 times – for the snapshots 0505, which was for some reason not announced, 0506, 0507, 0509, and 0510 (the last one fresh off the press). 0508 would have been ok, but QA was slightly slower than OBS and so the new snapshot moved to QA before the old one was completely tested. Oops. Anyway, nothing was lost, all good things from that snapshot are still shipped, just a day later.
So, what did those 5 snapshots bring you? The most interesting changes include:
* Mesa 22.0.3 * Mozilla Firefox 100.0 * KDE Plasma 5.24.5 * Meson 0.62 * gpg 2.3.6: Up to five times faster verification of detached signatures * Linux kernel 5.17.5 * gnome-shell & mutter 42.1 (late arrivals to the GNOME 42.1 update) * Poppler 22.05.0 * Virtualbox 6.1.34 * GCC 12.1 – with snapshot 0510, gcc12 has become the distro default compiler. All packages have been attempted to be rebuilt. This also means that the recently enabled FullRelRo support (-z now) is enabled across the board. There are currently about 370 build failures reported in openSUSE:Factory (non-ring packages) * systemd 250.5
This makes for quite an impressive list in just one week. Granted, a few of those things had been in staging areas for a while (days to weeks).
And as you’re already used to, this is no reason to stop. Au contraire: the stagings are already filled again with the following presents:
* KDE Gear 22.04.1 * Attempting to build the distro using FORTIFY_SOURCE=3 instead of FORTIFY_SOURCE=2 * Linux kernel 5.17.7 * GStreamer 1.20.2 * Perl 5.34.1 * Python 3.10 as the default interpreter
Cheers, Dominique
I can't avoid to say _*THANKS*_ to all the people involved in the the OpenSUSE Tumbleweed Project! Best regards! -- Marco Calistri Build: openSUSE Tumbleweed 20220509 Kernel:5.17.5-1-default Desktop: XFCE (4.16.0)
Am 13.05.22 um 15:19 schrieb Dominique Leuenberger / DimStar:
* Attempting to build the distro using FORTIFY_SOURCE=3 instead of FORTIFY_SOURCE=2
Is that really a good default though? The RedHat blog [1] writes
Earlier _FORTIFY_SOURCE levels rely on constant object sizes; because of this, the runtime overhead is negligible. _FORTIFY_SOURCE=3, however, changes that because expressions used to compute the object size can be arbitrarily complex. Complex expressions can add arbitrarily more runtime overhead. Further, consider the possibility of do_something in the previous example being called in a loop; the overhead gets magnified. This was a good enough reason to not sneak this new functionality in under the hood. The new level lets developers tinker around with it and decide whether the overhead was acceptable for their use case.
On 5/14/22 00:48, Aaron Puchert wrote:
Am 13.05.22 um 15:19 schrieb Dominique Leuenberger / DimStar:
* Attempting to build the distro using FORTIFY_SOURCE=3 instead of FORTIFY_SOURCE=2
Is that really a good default though? The RedHat blog [1] writes
Earlier _FORTIFY_SOURCE levels rely on constant object sizes; because of this, the runtime overhead is negligible. _FORTIFY_SOURCE=3, however, changes that because expressions used to compute the object size can be arbitrarily complex. Complex expressions can add arbitrarily more runtime overhead. Further, consider the possibility of do_something in the previous example being called in a loop; the overhead gets magnified.
Hi. We hope the overhead will be reasonable even though it's not so constant as FS=2. If there are affected packages, we can drop the fortification level for them. Martin
This was a good enough reason to not sneak
this new functionality in under the hood. The new level lets developers tinker around with it and decide whether the overhead was acceptable for their use case.
Am 16.05.22 um 08:44 schrieb Martin Liška:
On 5/14/22 00:48, Aaron Puchert wrote:
Am 13.05.22 um 15:19 schrieb Dominique Leuenberger / DimStar:
* Attempting to build the distro using FORTIFY_SOURCE=3 instead of FORTIFY_SOURCE=2 Is that really a good default though? The RedHat blog [1] writes
Earlier _FORTIFY_SOURCE levels rely on constant object sizes; because of this, the runtime overhead is negligible. _FORTIFY_SOURCE=3, however, changes that because expressions used to compute the object size can be arbitrarily complex. Complex expressions can add arbitrarily more runtime overhead. Further, consider the possibility of do_something in the previous example being called in a loop; the overhead gets magnified. Hi.
We hope the overhead will be reasonable even though it's not so constant as FS=2. If there are affected packages, we can drop the fortification level for them.
It might be hard to notice whether a package is affected because we don't regularly benchmark most packages. It probably doesn't show up in profiles, because the checks are added inline. So unless it's very obvious (say an increase of 30% or so), I think it would just fall under the radar. I'd expect us to notice only a small portion of the regressions caused by this (whatever the total might be). Another issue is that e.g. more inlining might lead to more places where |__builtin_dynamic_object_size| can derive a size and thus more checks, possibly slowing down the code. That might be counterintuitive. Aaron
On 5/17/22 00:30, Aaron Puchert wrote:
Am 16.05.22 um 08:44 schrieb Martin Liška:
On 5/14/22 00:48, Aaron Puchert wrote:
Am 13.05.22 um 15:19 schrieb Dominique Leuenberger / DimStar:
* Attempting to build the distro using FORTIFY_SOURCE=3 instead of FORTIFY_SOURCE=2 Is that really a good default though? The RedHat blog [1] writes
Earlier _FORTIFY_SOURCE levels rely on constant object sizes; because of this, the runtime overhead is negligible. _FORTIFY_SOURCE=3, however, changes that because expressions used to compute the object size can be arbitrarily complex. Complex expressions can add arbitrarily more runtime overhead. Further, consider the possibility of do_something in the previous example being called in a loop; the overhead gets magnified. Hi.
We hope the overhead will be reasonable even though it's not so constant as FS=2. If there are affected packages, we can drop the fortification level for them.
It might be hard to notice whether a package is affected because we don't regularly benchmark most packages. It probably doesn't show up in profiles, because the checks are added inline. So unless it's very obvious (say an increase of 30% or so), I think it would just fall under the radar. I'd expect us to notice only a small portion of the regressions caused by this (whatever the total might be).
That's correct, however based on my preliminary measurements that overall code grows seems negligible and so I don't expect much more instructions from __builtin_dynamic_object_size. Note that result of the built-in call is very commonly shared with calls to malloc, realloc and similar functions. What can be problematic are memory-related functions (__memcpy_chk, __memmove_chk, __mempcpy_chk and __memset_chk), these can theoretically lead to a slowdown if being used in a loop. The other functions are string-related functions (__stpcpy_chk, ..) and these are overhead itself. I must agree that we as openSUSE really lack a package performance system. Martin
Another issue is that e.g. more inlining might lead to more places where |__builtin_dynamic_object_size| can derive a size and thus more checks, possibly slowing down the code. That might be counterintuitive.
Aaron
On 13. 05. 22, 15:19, Dominique Leuenberger / DimStar wrote:
So, what did those 5 snapshots bring you? The most interesting changes include:
* Poppler 22.05.0
This deserves a note, IMO: it is supposed to make okular to render non-latin1 characters in fill-in forms and notes in pdfs at last! regards, -- js suse labs
participants (5)
-
Aaron Puchert -
Dominique Leuenberger / DimStar -
Jiri Slaby -
Marco Calistri -
Martin Liška