[PATCH] rtld: cache cpuid results on the stack for intel

[Fabian Rast]

On Mon Feb 2, 2026 at 10:26 AM CET, Florian Weimer wrote:
> * Fabian Rast:
>
>> Does anyone have experience with slow cpuid that could explain whats going =
>> on?
>
> In the slow case, are you running on bare metal, or is it virtualized?

This is on bare metal. An Intel(R) Xeon(R) Gold 6430.

My supervisor has access to more hardware - here are the results for
different processors:

model name      : Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz
./selfexec_patch 1000 ran 1.03 ± 0.01 times faster than ./selfexec_master 1000

model name      : Intel(R) Core(TM) i9-7900X CPU @ 3.30GHz
./selfexec_patch 1000 ran 1.03 ± 0.02 times faster than ./selfexec_master 1000

model name      : Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
./selfexec_patch 1000 ran 1.02 ± 0.01 times faster than ./selfexec_master 1000

Note that these binaries are statically linked, which amplifies the
effect (less loader overhead...). For comparison, here is the Intel(R)
Xeon(R) Gold 6430 again:
./selfexec_patch 1000 ran 1.23 ± 0.04 times faster than ./selfexec_master 1000

It looks like there is something special going on with the 6430, or I
am missing something... It would be great if someone that has access to
a xeon gold 6430 could reproduce this.

>> The man page for getauxval defines several tags regarding the same
>> information that is queried in dl_init_cacheinfo, but the loader does
>> not try to read them and my kernel does not set them. If almost every
>> program wants this information, why is getting it through the aux
>> vector not the preferred approach?
>
> The tags are not used on x86-64, see “LD_SHOW_AUXV=1 /bin/true”.  The
> values the kernel computes would likely be different.

Good to know. Maybe it is worth mentioning that the values can also differ
between processes when they are determined through cpuid during startup.
For example, my "AMD Ryzen AI 9 365" has a hybrid architecture:
The P-cores report 16MiB shared cache, but the E-cores only 8MiB.
So I suppose if a process that started up on an E-core gets scheduled
to a P-core with more shared cache later, the values will be incorrect anyways.

Cheers,
Fabian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 293 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260202/ba9d66ea/attachment.sig>