Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

One basic use of cpu id cache is to speed up the sched_getcpu(3)
implementation in glibc. This is why I'm proposing it as a stand-alone

I don't think rseq is needed for faster getcpu.

User space has to be able handle stale return values anyways, as it
has no way to lock itself to a cpu while it is using the return value.
So it can be only a hint.

The original version of getcpu just had a jiffies based cache. The CPU
value was valid up to a jiffie (the next time jiffie changes), and then it
gets looked up again.

Processes are unlikely to switch CPUs more often than a jiffie, so it's
good enough as a hint.
 
This doesn't need any new kernel interfaces at all because jiffies is already
exported to the vdso.

It just needs a new entry point into the vdso that handles the jiffie
check.

-Andi