11 ms·

Why was everyone so obsessed with the idea of Optane as universal memory? From a consumer perspective, it was a fast small SSD that doesn't wear out. That was

Why was everyone so obsessed with the idea of Optane as universal memory? From a consumer perspective, it was a fast small SSD that doesn't wear out. That was enough to justify it's value at the prices it went for(Or at least it seems like it, I never personally used it). It didn't need any radical rethink of computing to be worth it. I'm not even a fan of the nonvolatile RAM idea. Rebooting is often the first thing we do to fix stuff. Modern computing trends towards regenerating from descriptions, not adding more persistent state. Persistent state can get messed up, better to be able to wipe and start over.

DeathArrow 3y ago
I think the idea is to have large persistent storage with the speeds of RAM. Everything would open instantly.
- eternityforest 3y ago
  That would be useful, but it wouldn't really replace RAM, or, if it did, we'd probably still wipe it every boot, to be in a known state. Outside of some specialized database applications, having an entire program running right in persistent memory seems like a bad idea. And even then, I'm assuming databases would still want strong separation between persistent stuff and stuff that can be restarted any moment, to minimize the surface area for problems to stay persistent in.
  - rwmj 3y ago
    Even if you don't use it for state, there's still a lot of code and read-only data that could benefit from being executed directly out of Optane.
tanelpoder 3y ago
As it's part of the memory domain, not some external block device, the CPU caches can cache it (64B cache line sizes) and maintain cache coherency across CPUs, NUMA nodes (and soon with CXL 3.x ?) across memory pools shared by many servers. So your programming model will be just using CPU loads & stores to access the individual bytes you need directly from the Optane storage, instead of having to do some 512B or 4kB DMA or memcpy to RAM first and then access what you needed. And it's persistent, so you won't need to have a separate layer of code for persisting your "cache" of data... One can ditch the "database block I/O" and "buffer cache" notion and just treat Optane as byte-addressable RAM on a server that will never reboot or crash... Of course in reality your server can always catch fire or have a hardware malfunction, so you'd need to replicate your data to some distant enough backup or DR instance... which (at least in mission-critical database context) negates some of the value of persistent low-latency I/O... If you need to wait for 1+ms for the remote WAL write to be acknowledged from a different AZ or region anyway, then having an 1 us local Optane write is not gonna change the whole commit latency that radically.
- rcxdude 3y ago
  There's not much here that requires optane as the underlying storage tech, though. CPUs can already treat PCIe devices as memory, and do the same caching work underneath it. Most modern SSDs are alreadying using PCIe, it's just the protocol on top of it doesn't support mapping the contents of the disk to memory like this, but there's no real reason they couldn't.
  - pbalcer 3y ago
    The reason is physics. NAND just isn't fast enough (and requires firmware wear-leveling, which can mess up latency) for this to be practical.
justinclift 3y ago
> Rebooting is often the first thing we do to fix stuff. Depends on the environment. That used to be the common approach for windows, less so for *nix systems.
- eternityforest 3y ago
  Linux is pretty good now about not having the whole system lock up, but restarting programs still seems to be the #1 troubleshooting action.
  - justinclift 3y ago
    Yeah. There's a large difference with restarting an individual application and the whole system though. Sometimes several minutes difference. ;)
redserk 3y ago
I've always thought this would be perfect for something like Redis to run on top of. You wouldn't have to necessarily worry about DB dumps since the backing storage would still be very fast but could survive reboots.
numpad0 3y ago
RAM in 2010s were more expensive - or rather, more capped than it is today. Consumer desktop platforms always had 4 Unbuffered DIMM slots, servers had multiples of four RDIMM slots, and typical UDIMM were up to 8GB per slot although there were some 16GB modules towards the end of DDR3 era. SSDs were less advanced but were already exceeding 128GB in size when Optane appeared. So there was significant hurdle going beyond 16GB per machine, and sales pitch for Optane was DRAM substitute at near-NAND density and cost. Which, if taken at face value, implied >64GB RAM without committing to server/workstation platforms. That was appealing, at least to me back then. Nowadays you can buy 4 sticks of 32GB DDR4 or DDR5 modules for ~$350, which makes a hypothetical 64GB Optane DDR3 module a rather moot point.

DeathArrow 3y ago

I think the idea is to have large persistent storage with the speeds of RAM. Everything would open instantly.

eternityforest 3y ago
That would be useful, but it wouldn't really replace RAM, or, if it did, we'd probably still wipe it every boot, to be in a known state. Outside of some specialized database applications, having an entire program running right in persistent memory seems like a bad idea. And even then, I'm assuming databases would still want strong separation between persistent stuff and stuff that can be restarted any moment, to minimize the surface area for problems to stay persistent in.
- rwmj 3y ago
  Even if you don't use it for state, there's still a lot of code and read-only data that could benefit from being executed directly out of Optane.

tanelpoder 3y ago

As it's part of the memory domain, not some external block device, the CPU caches can cache it (64B cache line sizes) and maintain cache coherency across CPUs, NUMA nodes (and soon with CXL 3.x ?) across memory pools shared by many servers. So your programming model will be just using CPU loads & stores to access the individual bytes you need directly from the Optane storage, instead of having to do some 512B or 4kB DMA or memcpy to RAM first and then access what you needed. And it's persistent, so you won't need to have a separate layer of code for persisting your "cache" of data... One can ditch the "database block I/O" and "buffer cache" notion and just treat Optane as byte-addressable RAM on a server that will never reboot or crash... Of course in reality your server can always catch fire or have a hardware malfunction, so you'd need to replicate your data to some distant enough backup or DR instance... which (at least in mission-critical database context) negates some of the value of persistent low-latency I/O... If you need to wait for 1+ms for the remote WAL write to be acknowledged from a different AZ or region anyway, then having an 1 us local Optane write is not gonna change the whole commit latency that radically.

rcxdude 3y ago
There's not much here that requires optane as the underlying storage tech, though. CPUs can already treat PCIe devices as memory, and do the same caching work underneath it. Most modern SSDs are alreadying using PCIe, it's just the protocol on top of it doesn't support mapping the contents of the disk to memory like this, but there's no real reason they couldn't.
- pbalcer 3y ago
  The reason is physics. NAND just isn't fast enough (and requires firmware wear-leveling, which can mess up latency) for this to be practical.

justinclift 3y ago

> Rebooting is often the first thing we do to fix stuff. Depends on the environment. That used to be the common approach for windows, less so for *nix systems.

eternityforest 3y ago
Linux is pretty good now about not having the whole system lock up, but restarting programs still seems to be the #1 troubleshooting action.
- justinclift 3y ago
  Yeah. There's a large difference with restarting an individual application and the whole system though. Sometimes several minutes difference. ;)

redserk 3y ago

I've always thought this would be perfect for something like Redis to run on top of. You wouldn't have to necessarily worry about DB dumps since the backing storage would still be very fast but could survive reboots.

numpad0 3y ago

RAM in 2010s were more expensive - or rather, more capped than it is today. Consumer desktop platforms always had 4 Unbuffered DIMM slots, servers had multiples of four RDIMM slots, and typical UDIMM were up to 8GB per slot although there were some 16GB modules towards the end of DDR3 era. SSDs were less advanced but were already exceeding 128GB in size when Optane appeared. So there was significant hurdle going beyond 16GB per machine, and sales pitch for Optane was DRAM substitute at near-NAND density and cost. Which, if taken at face value, implied >64GB RAM without committing to server/workstation platforms. That was appealing, at least to me back then. Nowadays you can buy 4 sticks of 32GB DDR4 or DDR5 modules for ~$350, which makes a hypothetical 64GB Optane DDR3 module a rather moot point.