I see where you're going with this. dmidecode seems to indicate that the description from the actual RAM is lacking transparency about it's internal geometry.

I see where you're going with this. dmidecode seems to indicate that the description from the actual RAM is lacking transparency about it's internal geometry. I can get the ranking for slot-level interleaving from dmidecode on my systems (which means a kernel could or already has it as well). Thinking about the inside-chip geometry issue as well as the current on-list proposal in the news item I've reached a different potential solution. If page faults are tracked /by process/, the top N faulting processes could be put in to a mode where the following happens on a page fault: * Some semi-random process (theoretically not discover-able or predictable by user processes) picks a number between 1 and some limit (say 16). * The faulting page, and the next N pages, are read in (which should pull them in to the cache). This would help by making it harder to mount a /successive/ attack on different memory locations. Processes chewing through large arrays of objects in memory legitimately shouldn't be impacted that much by such a solution; surely less so than a hard pause on the process.