Why do the authors report performance at O0 and O1? AFAICT, the experiments are all single socket. There's an important difference in coherency overhead for si

Why do the authors report performance at O0 and O1? AFAICT, the experiments are all single socket. There's an important difference in coherency overhead for single VS multiple sockets; same for futzing with page protection. It also looks like they only tested a single producer/consumer pair. I expect page protection tricks don't scale as nicely when you have 20+ pairs on two sockets: contention on the page table and IPI storms. The mprotect trick also seems to depend on using small (4K) pages, unless you're OK with fairly stale data; probably not ideal for overall app performance. Also while they indirectly mention the batching trick of the disruptor (keep a reader-local copy of the write index and vice versa), it's not tested… and also not tested with a forced lag between the reader and the writer. If you want to avoid the ping pong, you can let the reader keep a copy of the writer's write pointer (and update the copy when the reader catches up), and artificially make the reader lag behind the writer. That lag gives much simpler code on the hotpath than the MCQueue they mention, which would be the closest equivalent to a laggy disruptor (keeping in mind that the disruptor pattern tends to be used in low latency settings, so that configuration is unlikely to be benchmarked, except indirectly, with cacheline-sized queue items). It's interesting work, but as is too often the case, the benchmarks give me no actionable information.