Travis (travis.downs.delete@this.gmail.com) on August 21, 2018 4:21 pm wrote:
>
> 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.

Yeah, a good approach is often just

- read current CPU number

- use atomic operation into an array indexed by that number.

and it works wonderfully well in practice.

Sure, you get the cost of an atomic operation, but since it's going to be to to was the percpu area just a few instruction ago, it's generally going to have good cache behavior and it will scale really well. If you are really really unlucky, and ended up scheduling to another CPU at just the right time, it still works because you used an atomic read-modify-write instruction.

So for statistics, this generally works fine, because the race is in no ways lethal to the model. The atomic access adds maybe 10-20 cycles just because it's not a normal access, but it doesn't cause the really nasty cacheline problems.

In fact, the most expensive part is often that "read current CPU number". You might be able to use "rdtscp" for it. Another few tens of cycles.

But rseq should basically be able to take those costs down to "a few regular instructions".

NOTE! rseq took a looong time to merge, and some of the early rseq patches did more than what was actually merged in the end. We decided to cut it down to the very bare essentials because I'm still a bit worried about how much use it will actually get.

We have a horrible track record with clever new features. Even when they sound really cool, people often just don't end up using them because they don't fit in the source base that has to support all the cases where the new feature isn't supported..

Linus