Paul A. Clayton (paaronclayton@gmail.com) on 1/4/12 wrote:
---------------------------
>David Kanter (dkanter@realworldtech.com) on 1/3/12 wrote:
>---------------------------
>[snip]
>>The economics don't make sense. As I mentioned in another
>>post, that means you need:
>>
>>1. An L4 cache controller
>
>This problem could be addressed by mapping the L4 cache as
>a region of memory and using the page table as tags. With
>nested page tables this could probably even be made
>transparent to the OS if desired. With a 256 MiB L4, 4 KiB
>blocks might not be horrible. The software managing the
>cache might run on one reserved thread of a modest-
>performance MT core.


Probably simpler just to have it be "normal" memory, just faster. OS's are becoming more-and-more NUMA aware, let the OS move hot pages to the fast memory.

I think that's attractive even for fairly ordinary DRAM - moving it on to the CPU package would likely let you halve latency without too much work. The CPU vendor could sell the CPU with approximately the "normal" amount of DRAM installed (the amount of fast RAM becomes an additional way to segment the market), and users could add external DRAM via the usual DIMMs.