5 ms·
The article does however mention the basic issue which led to Optane's failure (at least if I understand it correctly): that all current OSes have a concept of
by rob74 4y ago
The article does however mention the basic issue which led to Optane's failure (at least if I understand it correctly): that all current OSes have a concept of primary and secondary storage, whereas for getting optimal performance out of Optane, you need to have several levels of memory storage (which apparently have to be managed by the OS, as opposed to CPU caches): a program's code can stay in the Optane memory, while the stack and heap have to be in "real" RAM to reduce wear on the Optane memory when the program is executed? So Intel would have had to develop an OS for it, or worked on extending e.g. the Linux kernel in that direction.
- papruapap 4y agoI am a bit ignorant in OS stuff but isnt that managed by the filesystem? I think some people were using them as LOG drives in ZFS fs.
- rob74 4y agoThat's described in the article, that they could be used in Linux, but only as a volume. Apparently (if I read the article correctly) that wasn't optimal for exploiting the higher performance.
- voxadam 4y agoAs I understand it Linux's VFS and Block layer aren't really designed to exploit the type of throughput and latency that Optane provided. What I'm curious about is what happened to all the PMem (Persistent Memory) and NVRAM (Non-volatile RAM) work that went into recent Linux kernels and libraries.
- fweimer 4y agoI thought that with DAX, it was possible to have a real file system, but access to the actual bits goes straight to the backing storage, not the page cache (as it would with traditional block devices). So the block layer and VFS inefficiencies would not necessarily matter, at least if you can use DAX.
- rbanffy 4y ago> Apparently (if I read the article correctly) that wasn't optimal for exploiting the higher performance. That can be compensated by tuning the price point. If the performance isn't there, make it cheaper until it's better than the alternatives.
- amarshall 4y agoBe wary mixing Optane drives (what you seem to be referring to) and Optane memory (parent commenter).
- himinlomax 4y agoThere's already plenty of code to handle NUMA, it shouldn't have been too hard to add proper support for that.
- rbanffy 4y agoIt adds another layer - while NUMA is about latencies, Optane memory is about latency AND how frequently the information is changed (to minimize wear on the device). There are some obvious signals (disk caches would be one), but richer semantics would help a lot to make it perform.
- melony 4y agoThis is Itanium all over again
- soco 4y agoHardly an Intel specific problem (frowns at Alpha)
- rbanffy 4y agoItanium was a bet on compilers being able to extract parallelism from the source code. Maybe JIT optimizations, where code is rewritten on the fly, more or less the same way as a reordering buffer works, would have done the trick, but, in the end, Itanium fell short of its performance promises. I'm not sure compilers alone can do it.
- PaulHoule 4y agoThe trouble with Itanium was that memory latency is a limiting factor. A CPU knows what is in the cache but the compiler doesn’t. In fact, a major use of parallelism in CPUs is to hide latency and that involves a flexibility of scheduling greater than bundling groups of instructions together. (Think of 3 instructions hanging because 1 needs to load something as opposed to a system which might be able to barrel on and run a few non-dependent instructions.)
- rbanffy 4y ago> A CPU knows what is in the cache but the compiler doesn’t. You could kind of try to sidestep that by inserting preload instructions ahead of the instructions that would use the values but I agree that doing that at runtime would probably be better. Maybe a JIT runtime could help, but, still, that's beyond the control of the compiler.
- acje 4y agohttps://www.researchgate.net/publication/3044999_Beating_in-Order_Stalls_With_Flea-Flicker_Two-Pass_Pipelining https://www.researchgate.net/publication/3044999_Beating_in-... This one was never realized AFAIK, but addresses a lot of the latency issues of the IPF designs due to their relatively static nature. Still does not take the massive cost of reservation stations. I think being open will be a major requirement going forward. It is hard to build trust in a black box and RISC-V is about to become a real alternative. Being modular, open and growing up from smaller systems seems like a winning strategy to me.
- xxs 4y ago> or worked on extending e.g. the Linux kernel in that direction. Iirc Intel was the biggest code contributor for 2021 to the kernel. So they already have the expertise. Running code from Optane would likely be a mistake, though. Jumps would be very expensive due to the extra latency (unless they hit the cache). Perhaps it can work with page swaps but still.
- gumby 4y agoFWIW this article, like The Register articles of olde, did bring this point up. Multics had this concept back 60 years ago; like many useful Multics ideas (cough security) it was jettisoned in Unix. Most interestingly, Organick’s book describes a hierarchy of fast to slow, with the slowest being tape backup :-). More recently HP’s “The Machine” was designed this way — the article touches on this but if you don’t know what they are talking about that HP paragraph looks like it was accidentally jammed in. With the increased use of databases and key stores plus the dominance of mobile platforms, this single store model will probably be back.
- lproven 4y ago> like The Register articles of olde Coo, thanks! That is what I'm going for, yes. :-) Or at least, when I have the time, it is, anyway... (If it's not obvious, I wrote the linked article.)