Linus Torvalds (torvalds.delete@this.linux-foundation.org) on August 21, 2018 3:31 pm wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on August 21, 2018 2:34 pm wrote:
> >
> > I Again, rseq is designed for per-cpu lockless algorithms. The main use case is
> > literally a percpu memory allocator that doesn't need to take locks. There are others, but
> > memory allocators can be so critical that you might as well see that as the primary one.
>
> Actually, another thing worth mentioning is just "statistics".
>
> It sounds ridiculously easy to do things like "count number of packets processed" or
> "count hash misses vs hits", but it turns out that in heavily threaded environments, doing
> things like operation statistics is sometimes some of the nastiest stuff there is.
>
> It's trivial to do per-thread: just increment the counter in the per-thread area. Boom. Done.
> There are no races, because even on the worst kind of load-store machine you can just do
>
>

get thread pointer
> load counter from memory off thread pointer
> increment counter
> store new counter off thread pointer

> and you're done. No locks, no cache conflicts with other threads, no nothing.
>
> The problem with the per-thread model is that it can be very expensive indeed to add all those per-thread
> statistics up. Thousands of threads is not even unusual. So maybe you can deal with some slop, and just have
> the threads periodically empoty their per-thread statistics into some cache-coherent pool or something.
>
> It's solvable, don't get me wrong. But it has problems.
>
> So you can solve it other ways. One way is to have the remote atomics, and just do the statistics update
> "somewhere else" and asynchronously. That's a lovely model in many ways, but it's not portable.

"Remote atomics"? "Lovely model"? Who is this crazy person impersonating Linus?

I assume you mean each core sending a non-cache-coherent message off core somewhere (a memory controller?) which atomically increments a single location. That's crazy. First of all you have the same scaling problem, now you just offloaded it to the non-coherent messaging system and the entity performing the remote atomic. Secondly, high performance use cases that would care (like networking) literally count cache misses (or any type of operation that goes out of the core). Adding one more per packet might cut your performance by double digit percentages.

And no it often doesn't really matter if they are asynchronous because at the rates involved, and when interconnects and memory traffic is hot, and with any amount of contention, these queues are going to get backlogged.

Just don't do it. Asking CPU designers to do something like that is like giving them a rope you've tied around your own neck and telling them that if they tie the other end to their neck then you both jump off a cliff together, you'll finally reach the end of the magical leprechaun's rainbow. And they'd happily do it too.

No, just tell them to make the basics work fast and reduce the corner cases and pathologial cases. If a CPU designer starts telling you about remote atomics, tell them instead to spend all that research and development effort on making local atomics 5% faster. I guarantee that will be more useful.