| Summary: | sys-libs/glibc-2.33 changes behavior resulting in performance regressions for some applications | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Chris Jowett <cryptk> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://corelight.blog/2021/05/13/tracking-down-a-glibc-regression/ | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | `ebuild glibc-2.33-r1.ebuild clean prepare` output | ||
|
Description
Chris Jowett
2021-07-06 04:29:37 UTC
Thanks for the report and bringing this to our attention. (In reply to Chris Jowett from comment #0) > I would highly recommend reviewing the information at > https://corelight.blog/2021/05/13/tracking-down-a-glibc-regression/ as they > did a lot of work tracking down exactly what happened and how. > > There is a newer commit to glibc which fixes this problem, but it does not > appear to be in the version that Gentoo is currently shipping (2.33-r1). > It's a bit late here but are you sure? I see https://gitweb.gentoo.org/fork/glibc.git/commit/?h=gentoo/2.33&id=1fafc22294c5b0398c732f8e79a586c020021557 which was before we tagged 2.33-4 of our patchset. glibc-2.33-r1 is using PATCH_VER=4 which corresponds to that tag. I could be wrong, but what I am seeing in strace looks an awful lot like what is spoken about there. I guess it could be a similar performance problem with some element of python perhaps. Created attachment 722140 [details]
`ebuild glibc-2.33-r1.ebuild clean prepare` output
Hm, it does seem to be included:
* 0031-tst-Provide-test-for-select.patch ... [ ok ]
* 0032-misc-Fix-tst-select-timeout-handling-BZ-27648.patch ... [ ok ]
* 0033-libsupport-Add-support_select_modifies_timeout.patch ... [ ok ]
* 0034-libsupport-Add-support_select_normalizes_timeout.patch ... [ ok ]
* 0035-linux-Normalize-and-return-timeout-on-select-BZ-2765.patch ... [ ok ]
* 0036-linux-always-update-select-timeout-BZ-27706.patch ... [ ok ]
* 0037-tunables-Fix-comparison-of-tunable-values.patch ... [ ok ]
* 0038-support-Typo-and-formatting-fixes.patch ... [ ok ]
* 0039-support-Pass-environ-to-child-process.patch ... [ ok ]
* 0040-support-Add-capability-to-fork-an-sgid-child.patch ... [ ok ]
* 0041-tst-env-setuid-Use-support_capture_subprogram_self_s.patch ... [ ok ]
well, I would have tested with an older version of glibc, which would have verified for sure if I was suffering some kind of a regression, but everything I am reading in the ebuild warning as well as on the gentoo wiki basically says that if I do that I have a pretty high chance of breaking my system. (In reply to Chris Jowett from comment #5) > well, I would have tested with an older version of glibc, which would have > verified for sure if I was suffering some kind of a regression, but > everything I am reading in the ebuild warning as well as on the gentoo wiki > basically says that if I do that I have a pretty high chance of breaking my > system. No, I understand of course. Could you: - give some instructions on how to reproduce? (it's okay if it's complicated, it is what it is) - share the strace output - share emerge --info? I'll try and get you that information in the morning, thanks! (In reply to Chris Jowett from comment #0) > I would highly recommend reviewing the information at > https://corelight.blog/2021/05/13/tracking-down-a-glibc-regression/ as they > did a lot of work tracking down exactly what happened and how. > > There is a newer commit to glibc which fixes this problem, but it does not > appear to be in the version that Gentoo is currently shipping (2.33-r1). > > I'm not sure what would need to be done to correct this as I am not a Gentoo > maintainer, but perhaps there could be a patch added to the ebuild which > implements the fix in > https://sourceware.org/git/?p=glibc.git;a=commitdiff; > h=9d7c5cc38e58fb0923e88901f87174a511b61552 > > Reproducible: Always Your link has a minimal test, it does not fail for me on glibc-2.33-r1: $ gcc a.c -o a && ./a tv before: 4.000000 Data is available now. tv after : 1.999674 select: OK > Steps to Reproduce: > I was able to reproduce the problem consistently with an application named > plotman (a python application), but I'm not sure how feasible it is to ask > people to set that up. So far I haven't found any other applications (yet) > that are affected. Can you share exact steps to execute to observe the change? Is it a filesystem-heavy application? There is a small chance that #773436 might be responsible (easy to check by reverting /etc/nsswitch.conf locally). So I had an unplanned change of events and I don't (and won't) have access to that Gentoo system for quite a while. That said, I was able to also replicate the issue in Ubuntu 21.04, so I don't think this is a Gentoo specific problem. We can go ahead and close this ticket (In reply to Chris Jowett from comment #9) > So I had an unplanned change of events and I don't (and won't) have access > to that Gentoo system for quite a while. That said, I was able to also > replicate the issue in Ubuntu 21.04, so I don't think this is a Gentoo > specific problem. > > We can go ahead and close this ticket That's a good bit of information. Thank you! |
