51–60 of 75 posts
I guess in a theoretical NVM-only system you could pull the plug at any time, and instantly resume it when the power is back on? If I'm reading right though the latency of 3DXP is somewhere in the 10-20us ballpark, still 100-1000x slower than DRAM.
Would be to save them when you notice power loss.
While there are some analytics workloads that will benefit tremendously, the main use case will be improving server utilization. Currently RAM is not a compressible resource like CPU. However many applications don't have a fixed or if easily predictable RAM footprint and so you have to overprovision. Swap has been there to solve that but with its performance impact, it often can't be used for server applications. The…
You shouldn't work in political marketing :-)
Why can't we just put a battery onto DRAM that maintains state if the power goes out, and be done with it?
Earlier quoted context omitted.
Moving 3D XPoint memory from the peripheral IO bus to the memory bus is way more than an incremental improvement.
Says the company that claimed it would be 1000x faster than NAND flash, it isn't, and moving the location of the bus isn't going to change that.
Using the IO bus instead of the memory bus is exactly why existing Optane products haven't delivered latency that's 1000x better than NAND flash. NVMe transactions take at least 5-10µs even with DRAM as the SSD media rather than NAND flash or 3D XPoint. Moving to the memory bus is a prerequisite to 3D XPoint fulfilling those original performance claims.
While there are some analytics workloads that will benefit tremendously, the main use case will be improving server utilization. Currently RAM is not a compressible resource like CPU. However many applications don't have a fixed or if easily predictable RAM footprint and so you have to overprovision. Swap has been there to solve that but with its performance impact, it often can't be used for server applications. The…
Earlier quoted context omitted.
Seriously, yes. If there was ever a time to rethink OS design, surely this is it. That being said, operating systems like Linux tend to capture most of the value from these kind of advances - often by dint of being able to simply 'get out of the way' if a sufficiently important user space process wants access to the device. But one would suspect that things have changed sufficiently from the 1970s to warrant a ground…
> Seriously, yes. If there was ever a time to rethink OS design, surely this is it. Why? Traditional servers are persistent: they never turn off. 500+ days of uptime is typical. And today, with VMs which at worst... hibernate... it seems like "never turning off" might be the norm.
A traditional spinning rust HDD has an effective latency of ~10 ms. The NVME version of the 3DXP has an effective latency of ~50 us, or two orders of magnitude better. Not sure how low the DIMM version will go, but maybe another order of magnitude?
If so, we're talking three orders of magnitude difference. That would radically affect the assumptions going into storage algorithms. Suddenly you can no longer spend millions of instructions trying to avoid I/O. Batching of I/O is also not needed to the same degree. Complex syncing of memory and disk is not needed. Etc etc.
On a few occasions I've found myself in the presence of a senior engineer at a large defense company who would never stop talking about how persistent memory will change everything forever. Fair enough, but he'd go on about it in the weirdest ways. I think his impression is that the CPU registers would also be nonvolatile. I'm concerned that guy might be a few electrons short of a full orbital.
It seems obvious in retrospect, but persistent memory adds a pretty exciting new advantage for persistent data structures. Another thought: As potentially paradigm changing technology like this becomes available will it ever make sense to redesign the OS?
Zero serialization. Imagine installing a program and always having it "running". It may be swapped out but littetally everything in it is ready to go when you switch to it's window.
This is a huge PITA with mobile devices - I have no clue what code is, or isn't, being executed at any given time. Even if I force-kill an app, it has still most likely left some background service running, that will still use data, trigger GPS updates, wake the phone up, etc. What I wanted since the very day I first got my smartphone is to have PC-like control over applications.
In a perfect world of total ubiquity of wireless electricity, not to mention infinite CPU speeds and free and unlimited bandwidth, having everything running all the time in some way might be ok. As it is today, we still need the ability to kill software (and have it stay down), up to and including rebooting everything, to deal with obscure bugs in applications, OS and drivers. Not to mention being able to have some semblance of understanding of the device's state.