Bug#1053241: glibc: please apply upstream patch to fix slow fstat
Il giorno dom 26 nov 2023 alle ore 16:28 Aurelien Jarno
<aurel32@debian.org> ha scritto:
>
> Hi,
>
> On 2023-09-29 21:52, Fabio Pedretti wrote:
> > Package: glibc
> > Version: 2.36-9+deb12u1
> > Severity: normal
> > X-Debbugs-Cc: pedretti.fabio@gmail.com
> >
> > Dear Maintainer,
> >
> > glibc uses a slow version of fstat. Details are documented
> > here: https://lwn.net/Articles/944214/
> >
> > A patch to fix this was merged in glibc:
> > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=551101e8240b7514fc646d1722f8b79c90362b8f
> >
> > The patch applies cleanly and builds fine also on bookworm glibc.
> > Please consider apply it to fix slow fstat.
>
> This patch changes the syscall used by binaries, so it has to be
> considered with a lot of care in a stable release, it could break
> existing seccomp filters. In any case it has to live a few months in
> testing/unstable first.
>
> Note that the kernel patch that improves the performance of fstatat, has
> not been merge to the upstream stable tree, nor to bookworm.
>
> In order to better understand the need for this patch in bookworm, could
> you please give some details about your workload and the performance
> impact it has?
I did some test with my use case, borg backup with many unchanged
files, see https://github.com/borgbackup/borg/issues/4498 for some
background and system calls impact, where borg 1.2 slow downs a lot
vs. borg 1.1.
I checked using strace the patch, it did the job (newfstatat calls
were replaced with fstat), and I'd hoped that it would improve
performance, however my use case improved just marginally (difficult
to have reproducible data in my case, but it was like 5%).
I didn't notice any other regression, however.
I see the glibc patch is still only on 2.39, while even Debian
experimental has just 2.38.
The alternative kernel patch is in 6.6 (as you say, still not in Debian).
Given all of this, I agree we can wait to land it on trixie and leave
bookworm as is, so feel free to just close the issue in this case.
Thanks for your time.
Reply to: