Flexi-Plexistor's software-defined memory roadmap

Startup Plexistor's SDM software is said to run any application at near-memory speed by using caching and tiering. It has a file system that covers DRAM, NVDIMM-N (byte-addressable flash DIMMs fully mapped to memory space and accessed at cache-line granularity), NVDIMM-F (block-addressable flash DIMM on memory bus), forthcoming …

[Detective Emil]

Someone call the fire brigade!

My buzzword detector just went up in in flames.

[Anonymous Coward]

Sounds rather like swap / virtual memory

"...liberating it from the overhead of the ordinary Linux operating system's I/O stack and the constraints of decades-old conventional storage architectures"

Alternative interpretation:

"...hiding the details of a multi-tier storage hierarchy from the application, so that it cannot perform its own optimisation or select which type of memory is most appropriate for each activity"

Also, how does the application control persistence? If there is a single unified address space, what's the difference between writing a temporary variable to RAM (which you don't care about losing if the application crashes), and writing a piece of user data that you want persisting? And, how does the OS signal back to you when that data has made it through to persistent storage - the equivalent of "write barriers"?

[jake]

I'm fairly certain that ...

... my small cluster of vaxen (late 1970s to early 1980s vintage) contain MMUs that already perform this in hardware ... as do my small collection of early Sun kit. And it's a hell of a lot faster than any software variation.

Kids these days brought up on "personal computers" have no actual clue about computing.