[TeapotNotKettle]

Very interesting work.

But practically speaking, in a real application - isn’t any performance benefit going to be lost by the reduced cache hit rate caused by having a larger working set? Or are the reads of all-but-one of the replicas non-cached?

Apologies if I am missing something.

[6keZbCECT2uB]

Once your cache hit ratios for some data structure go < .1%, I'd rather have 75% less tail latency even if it reduces cache hit rate further.

[TeapotNotKettle]

Maybe - but if that’s the case you are likely using the wrong data structure.

Additionally you are going to be memory starving every other thread/process because you are hogging all the memory channels, and making an already bad L3 cache situation worse.

Outside of extremely niche realtime use cases (which would generally fit in L3 cache) I can’t see how this would improve overall throughput, once you take into account other processes running on the same box.

Do you have an example use case?

[rbanffy]

> Do you have an example use case?

The one that comes to mind is HPC, where you avoid over allocation of the physical cores. If the process has the whole node for itself for a brief period, inefficient memory access might have a bigger impact than memory starvation.

IBM also has their RAID-like memory for mainframes that might be able to do something similar. This feels like software implemented RAID-1.