Home
from Hewlett Packard Enterprise and HP Labs
The Machine is a prototype system and architectural showcase built around memory-centric computing. Much more background information can be found at the official HP Labs website for The Machine This wiki provides more insight into the section of The Machine know as Fabric-Attached Memory. After perusing it, the README of the actual repo should make much more sense. Then you can clone the repo and create an emulation environment that mimics the fabric-attached memory of The Machine.
The Machine is a collection of up to eighty nodes; each node has both some private and shared resources.
- An SoC (and attached DRAM) runs copy of GNU/Linux derived from Debian Jessie
- Several terabytes of Non-Volatile Memory (NVM) which is byte-addressable
- Proprietary "bridge" ICs that tie all nodes together in the memory fabric
The primary purpose of the bridge is to translate and route memory access from any SoC to any other node's NVM. This is represented in the above diagram: the bridges on the top and middle nodes have been program to provide the top SoC with access to the middle node's NVM.
With the right settings multiple SoCs can "see" a common, global, byte-addressable load-store domain that can span dozens to hundreds of terabytes. This is the Fabric-Attached Memory of The Machine.
Note that the SoCs cannot see each other (or their DRAM) across the fabric.
The NVM is persistent, and as it's byte addressable, accessed by memory reference load-store operations. This is no-IO storage: no more read(2)/write(2) system calls to move data in and out for your program. Everything is done in a memory-mapped style. Imagine this:
struct mystruct *myptr = allocate_fabric_attached_memory(.......);
myptr->myfield = 42;
The data is persistent with access times much faster than flash. Now we just have to write that pesky library API allocate_fabric_attached_memory, but how can that be done when the execution platform is still being designed?