On Wed, Jul 17, 2024, at 06:02, Linus Torvalds wrote: > On Mon, 15 Jul 2024 at 14:07, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > But that's not at all what I see. It rebuilds pretty much the whole > tree (not quite everything, but at an estimate it rebuilds the > majority of files). > > And the first things I see in the build log is > > SYSHDR arch/arm64/include/generated/uapi/asm/unistd_64.h > SYSTBL arch/arm64/include/generated/asm/syscall_table_32.h > SYSTBL arch/arm64/include/generated/asm/syscall_table_64.h > SYSHDR arch/arm64/include/generated/asm/unistd_32.h > SYSHDR arch/arm64/include/generated/asm/unistd_compat_32.h > HDRINST usr/include/asm/unistd_64.h > CC arch/arm64/kernel/asm-offsets.s > CALL scripts/checksyscalls.sh > ... > > which is why I'm suspecting your changes without having actually > bisected the build time regression at all. Right, I can confirm that this is not supposed to happen, and it didn't do that for me during my testing. It should only recreate asm/unistd_64.h if scripts/syscall.tbl changed, as it does on the architectures that are using the "archheaders:" rule to get into the architecture specific arch/*/*/syscalls/Makefile/. > This needs fixing, urgently. Because it turns a "small pull" into > always taking 5+ minutes for me. I didn't notice immediately, because > many of my core pulls I _expect_ to rebuild everything, but... > > Btw, I don't see the same effect on x86-64, so this is purely an arm64 > issue (well, and presumably any other architecture that uses > 'syscall-y'). > > You might want to do a build like this: > > make allmodconfig > make > > twice, and then do > > find . -newer .config -name '*.h' > > to find things where the build has generated header files with new > timestamps despite no changes. I tried now both with my branch and with your latest commit 51835949dda3 ("Merge tag 'net-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next") but can't reproduce it yet. My first guess was that this might be related to building inside the source tree rather than a separate object tree (which I used for my own testing), but that did not make a difference either. > I'm adding Masahiro to the participants, because of some of the other > files that *do* show up for me when I do the above thing: > > On x86: > arch/x86/boot/voffset.h > arch/x86/boot/zoffset.h > security/apparmor/net_names.h > > On arm64 (ignoring the above and the syscall ones): > include/generated/vdso-offsets.h > > That 'find' also shows that the install headers thing does the same to > the ./usr/include/ directories, but the kernel build doesn't care > about those. I don't see those either (this is an x86 defconfig example): $ find . -newer .config -name '*.h' ./include/generated/autoconf.h So whatever caused the regression is probably a result of my changes, but so far I haven't been able to explain or reproduce it. I'll keep looking. Arnd