Linus Torvalds (torvalds.delete@this.linux-foundation.org) on August 21, 2018 3:31 pm wrote:

> That kind of silly low-level thing that sounds trivial - but really isn't - is what rseq is about.
> Things that sound so simple that you'd not even realize that they are hard to implement.

Yup. I've seen some ugly stuff to try to emulate this percpu behavior.

For example, mapping the perf_event_mmap_page into the process just to access the perf_event_mmap_page->lock field, which increments on context switches, solely so that threads can detect a context switch by quickly reading this field and update their thread-local CPU value.

Also I've seen a watchdog thread that sits monitoring the scheduler however it can (e.g., via kprobes or just reading /proc//task periodically) and updating every thread's view of its current CPU so that the threads themselves can get the current CPU via a plain read.

Both of these are inherently racy, but for statistics it usually doesn't matter (and even when the primary race happens and you get the wrong CPU number, you usually don't get any missed events because your update also have to race with a thread that thinks it is running on the same CPU as you, and such threads are usually not running.

rseq will be ideal for those use cases.