Upcoming glibc 2.33 freeze in 2 weeks.
Romain GEISSLER
romain.geissler@amadeus.com
Sun Jan 3 20:43:38 GMT 2021
> Le 3 janv. 2021 à 14:12, Carlos O'Donell via Libc-alpha <libc-alpha sourceware ! org> a écrit :
>
> Your patches are an important change and we should get to
> reviewing them again this release.
>
> Florian has fixed a number of important issues in the loader
> that make me less worried about corner cases with NODELETE,
> audit loading, and early startup sequencing.
>
> Florian has assigned himself for review of the v3 patches
> (delegate in patchwork). Him and I discussed this patch set
> specifically. I see v4 in patchwork now, thanks!
>
> --
> Cheers,
> Carlos.
Hi,
FYI, we (Amadeus) are very glad with the work by Chung Lin done in these patch proposal. It happens that the problems described in the different bugzilla did happen internally in one very specific backend server application in Amadeus (just one application out of tens of thousands existing, yet this one is definitely at the core of our business, so it had to be fixed one way or another). In may 2020, following a migration from an even older glibc to glibc 2.23, we did hit performance problem with a large number of DSO loaded (order of magnitude: about 1000 shared libraries) having unusual dependencies and coupled with many manual dlopens (to be honest, I haven’t even tried understood what is so specific about this application). I (tried to) backport this patch the best I can to the years old glibc 2.23, and for this specific application, it did fix their issues (it’s running in production one thousands on servers since roughly 6 months).
In addition to that, in the latest version of the Amadeus C++ middleware, which is right now not loaded in production with any significative numbers to be meaningful, but still used daily for now just in development environment by a small subset of our teams (let’s say about 100 C++ developers in Amadeus working mainly on middleware, partially in final backend applications), these patches, applied on glibc 2.32 and enabled by default have not created any issue that we could notice. Yet, we definitely have a rather simple DSO usage (and usually homogenous), much simpler than what can be found in all the open source packages of a linux distro.
Anyway, my point was: we are partially running backport of these patches in production or these exact patches in development environment since 6 months, and we haven’t noticed any impact (except of course fixing our DSO loading/unloading performance problems).
Cheers,
Romain
More information about the Libc-alpha
mailing list