> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
