Linux: Controlling access to the memory cache
This is made to sound so revolutionary and novel but in fact it is only an intermediary, fast, transparent to the processes, automatically managed memory. Badly managed as it turned out. What hurts the most is that there definitely is some sort of influence on how a process can take advantage of caching, yet <i>not in its control</i>, and even with the best practices on memory optimization it all falls flat when a few processing layers get stacked on this hardware clever cache memory management. The fast memory should have been left in the control of the software. It should have been left small and accessible like in the old computers (16 bit range) and what is now considered &quot;the main memory&quot; to be developed as a new thing, that could be left to grow massively. I think that the current situation is less the result of quality engineering vision and more of the result of marketing departments putting pressure on the development teams to come out with clever tricks to beat the competition.<p>___________<p>P.S.: I already thought about the backward compatibility considerations being primordial. That would have meant that the technical advancement transparent to the existing usage was a reason in itself, but that doesn&#x27;t quite hold water. The 16 bit to 32 bit architecture switch opened the possibility of adopting a secondary (but slower) layer of RAM going over 64 KiB and keeping the 16 bit  manageable memory range close to CPU, as (at least one of) the cache layers.