* Andy Lutomirski:
The theory is that people thought that getcpu was going to be kind of slow, so userspace would allocate a little cache (IIRC per-thread) and pass it in, and the vDSO would do, well, something clever to return the right value. The something clever was probably based on the idea that you can't actually tell (in general) if the return value from getcpu is stale, since you might well get migrated right as the function returns anyway, so the cache could be something silly like (jiffies, cpu).
It probably had to do something with per-CPU or per-node mappings of the vDSO. Or may some non-coherent cache line in the vDSO. As far as I understand it, the cache has zero chance of working with the way vDSO data is currently implemented.
We have the CPU ID and node ID in the restartable sequences area now (although glibc does not use the node ID yet). It's not a cache. So this clearly supersedes whatever struct getcpu_cache tried to achieve.
Thanks, Florian