Slashdot Mirror

← Back to Stories (view on slashdot.org)

Researchers Invent a Way to Speed Intel's 3D XPoint Computer Memory (ieee.org)

Posted by msmash on from the new-innovations dept.

Memory modules using Intel's 3D XPoint technology are on their way, and researchers in North Carolina have already figured out how to make them better. New submitter mnemotronic writes: At the 45th ICSA (International Symposium on Computer Architecture), a group of researchers from North Carolina State University led by Prof. Yan Solihin proposed a method called lazy consistency to speedup write operations to 3d XPoint memory. XPoint, developed by Intel and Micron, is non-volatile, cheaper and denser than DRAM but requires more power and writing takes longer. The method proposed reduces write overhead times from 9% to 1% by incorporating a checksum to the cache memory system. The researchers were not able to verify their approach on actual XPoint memory, as those products only recently started sampling. They tested using simulations and DRAM and plan to verify when Intel's modules become more widely available.

25 of 43 comments (clear)

  1. ICSA? by ScienceofSpock · · Score: 1

    It's ISCA.

  2. Re:MRAM vs...? by Forever+Wondering · · Score: 2

    Probably. IIRC ...

    MRAM consumes less power than DRAM (vs. more). MRAM is _faster_ than DRAM (and is as fast as L2 cache).

    It also has a very small bit cell size (so very high density).

    So, it beats out 3D-XPoint (aka Optane) on almost every point.

    Also, MRAM doesn't "wear out". From what I've read, 3D-XPoint is better than flash on this, but, eventually, has a wear out point.

    --
    Like a good neighbor, fsck is there ...
  3. No, it's ISAC by Brannon · · Score: 1

    International Symposium on Confusing Acronyms

    1. Re:No, it's ISAC by TeknoHog · · Score: 1

      I'll accept ISAC as an acronym, but ISCA, not so much (though they both are initialisms and abbreviations).

      --
      Escher was the first MC and Giger invented the HR department.
  4. Just a value question by Kjella · · Score: 1

    3D XPoint memory is in between NVRAM which is RAM backed by supercapacitators, running some kind of kind of machine/rack-level UPS to ensure RAM is saved to "regular" flash drives or just persisting against NVMe drives before declaring the transaction complete. So there are faster and more expensive options and slower and less expensive options and it also depends on how many components you want involved. But that's always a discussion, if a disgruntled data center worker takes a sledgehammer to your machine it's not really persisted enough until it's hit your hot swap / cluster / backup. So if Intel can deliver the right price-performance value that's great, if they can't... no big deal. There are alternatives, if you need them.

    --
    Live today, because you never know what tomorrow brings
  5. MRAM could be better than Xpoint by johnjones · · Score: 1

    as stated above MRAM is _faster_ than DRAM and therefore much better than XPoint/Optane

    what is needed is a foundry that wants to dominate...

    1. Re:MRAM could be better than Xpoint by evanh · · Score: 1

      MRAM is at least as dense as DRAM on the same process tech, and potentially denser than DRAM at finer processes. Just no one is making MRAM in anything like the latest process. The chicken and egg scenario here. And probably a lot of patents slowing things down too.

      MRAM doesn't inherently use more power. STT-MRAM, more than a decade ago, reduced the write-current requirements a lot.

  6. Won't Work by sexconker · · Score: 4, Interesting

    The delay is because XPoint doesn't work. The writes usually take, but sometimes they don't. Intel hasn't figured out why.

    They current practice is to verify all the writes and simply redo them if they don't take.
    This means you're tying up the the bus, and this is why Intel now recommends dedicating entire memory channels to XPoint instead of mixing and matching with DRAM. If you have XPoint in all of your channels, your latencies go through the roof and your performance tanks.

    Wait for generation 3 before considering XPoint NVDIMMs.

    1. Re:Won't Work by swb · · Score: 2

      Why would you mix and match DRAM and Xpoint on the same bus anyway when Xpoint is so much slower than DRAM? Even without extra verification and writes its still much slower than DRAM and would seem to clog the channel.

      I'll admit that maybe I don't know something about existing DRAM access paths/channels/buses, AFAIK the NUMA node was basically the smallest subdivision. Or is it possible to address individual DRAM modules/pages in parallel with others on the same NUMA node?

      I guess I had figured that DRAM interfacing Xpoint was meant to be mostly a speed/simplicity thing, faster than PCI NVMe and meant to be on a distinct memory bus from DRAM.

      The application that came to mind was just using it as superfast block storage in maybe hyperconverged systems or monolithic DB servers.

    2. Re:Won't Work by DigiShaman · · Score: 2

      Would it not make sense to just create an NVMe SSD with Xpoint as the internal cache of the drive for the rest of the NAND memory in a single storage device?

      --
      Life is not for the lazy.
    3. Re:Won't Work by Junta · · Score: 2

      Note you can make numa domains smaller. It is quite plausible that 3d xpoint in 'memory' mode appears as a different NUMA domain with SLIT indicating higher penalty for use. NUMA is relatively expressive and can describe the high level divisions and implications of this sort of approach.

      A challenge for Intel is justifying sitting in a rather inconvenient DIMM slot. It may be able to deliver better performance rather than PCIe,, but even PCIe attached NVME has had a very protracted adoption cycle as the relative value of going from SAS/SATA SSD to PCIe attached SSD is not as dramatic (it's also debatable whether they needed PCIe so much as they needed NVM, SATA/SAS protocols baked in assumptions that do not apply to a highly parallel storage architecture, NVMe provides an alternative protocol with, for example, thousands more queues each thousands times deeper than anything in SATA or SAS).

      --
      XML is like violence. If it doesn't solve the problem, use more.
    4. Re:Won't Work by sexconker · · Score: 1

      Why would you mix and match DRAM and Xpoint on the same bus anyway when Xpoint is so much slower than DRAM?

      Because Intel originally said you s hould do this and that it would be awesome and that the memory controller knew how to make it all work out so you get DRAM speed for DRAM stuff and multi-channel XPoint speed for NV stuff.

      Nope.

    5. Re:Won't Work by sexconker · · Score: 1

      No. Existing NVMe SSDs already use DRAM for the cache, which is faster and more reliable than Xpoint.
      And you're bottlenecked by NVMe performance and latency.

      Xpoint was supposed to replace both DRAM and storage. Now it's a very expensive replacement for storage that's better in one metric (MAYBE two) and a very poor replacement for DRAM that's worse in every metric except cost. And until Intel actually starts shipping these things for sale to end users, that cost benefit is up in the air.

      I for one expect DRAM prices to settle back down (likely due to regulators finally shaking their stick against the collusion) well before Xpoint NVDIMMs make sense. Then the only benefits to Xpoint are latency on the storage side (in which case it's still likely much more expensive than NAND) and persistence on the memory side. If you need persistence in memory you're typically running supercap / UPS setups and flushing to disk. NVDIMM Xpoint could get rid of all that complexity, but at what cost?

      Xpoint's other claim to fame is durability. DRAM wins. It might beat out current NAND, but no one really has tested enough to be sure. Their currently shipping products have tons of overprovisioning on them despite Intel claiming it's not necessary at all because Xpoint is so resilient. Who knows?

    6. Re:Won't Work by swb · · Score: 1

      I kind of figured XPoint DIMM would wind up in alternative form factors oriented around hyperconverged architectures, something (much) smaller than blade systems that would allow many (6+) nodes in a 2-4U space without losing storage density in the process. Blown XPoint DIMMs would just be replaced by pulling the whole blade and swapping out DIMMs. By having many nodes you don't worry about losing compute capacity or redundancy.

      But I can never make hyperconverged work from a cost basis -- too many nodes required for redundancy and storage density is tough to get when you're chained to 2.5" disks without giant-ass servers. Then there's crappy licensing that is structured to recoup 95% (in actuality, more like 120%...) of the savings from not having a SAN. Plus there's too many new weird failure modes.

    7. Re:Won't Work by Junta · · Score: 1

      The problem is that xpoint dimms even as advertised capacity wise will lose out to U.2 drives for storage per unit volume.

      Never mind the probably-not-going-to-succeed-either ruler form factor which tries to get more SSD storage density by elongating the drives for optimizing SSD storage per unit volume without incurring crazy number of connectors.

      Hyperconverged in practice loves 2U servers with lots of drives. A lot of people love trying to make the argument for storage rich blade-dense form factors, but in practice the market doesn't really like the compromise (however much storage you can cram into a 0.5U server, you can always use the same techniques to cram *more* in the 2U). Today you can buy a half-u server with 100TB of SSD storage, but on the other hand, 400TB per server sounds nice and you don't need that much compute relatively speaking... so 2U it is.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    8. Re:Won't Work by Wookie+Monster · · Score: 1

      Citation needed? I've not found anything that says 3D XPoint doesn't work as you describe.

    9. Re:Won't Work by sexconker · · Score: 1

      https://semiaccurate.com/2018/...

      Charlie has been following and detailing Xpoint and its failures for a while now. He's got a half dozen articles or so with more specifics, including official marketing BS from Intel and how its changed over time. I haven't seen Charlie sink his teeth this deep into a story since bumpgate. If you remember that one, he was basically the one guy that bothered to do the legwork to prove an large number of Nvidia's GPUs were defective. This resulted in lawsuits against Nvidia and even caused Apple to move to AMD graphics.

    10. Re:Won't Work by torkus · · Score: 1

      You're missing the situations where you need to handle extremely large data sets.

      It's not common, but neither is the need for a Xeon 8180 yet they certainly exist (well, for the price of a cheap car).

      3d-xpoint RAM isn't going to outright replace DRAM any time soon, but it certainly can supplement it.

      --
      You can get rich if you own a politician, but you have to be rich to buy one in the first place.
  7. Re:lazy consistency by radarskiy · · Score: 2

    Speculation is about resolving predicates. Consistency is about resolving dependencies.

  8. No cited article by radarskiy · · Score: 1

    The summary includes NO link to any cited article, just links for defining the conference name, school, the professor, etc.

    1. Re:No cited article by Solandri · · Score: 3, Informative

      Ever since the Slashdot redesign a few years back, the main link to TFA appears to the right of the title, where it's easy to miss and not at all obvious that it's a link. But I imagine they paid some designer handsomely to make the site less usable.

    2. Re:No cited article by niittyniemi · · Score: 1

      The summary includes NO link to any cited article, just links for defining the conference name, school, the professor, etc.

      Also, to add insult to injury, TFS includes this nugget:

      The method proposed reduces write overhead times from 9% to 1% by incorporating a checksum to the cache memory system.

      That makes 0 Ohms sense.

      Clue for submitter & editor: the SI unit for time is the second, last time I looked.

      --
      The Machine stops.
    3. Re:No cited article by torkus · · Score: 1

      Also, to add insult to injury, TFS includes this nugget:

      The method proposed reduces write overhead times from 9% to 1% by incorporating a checksum to the cache memory system.

      That makes 0 Ohms sense.

      Clue for submitter & editor: the SI unit for time is the second, last time I looked.

      This makes perfect sense. Write overhead time as a function of the overall write operation is absolutely the correct measurement in this context.

      It communicates three critical information points (the previous overhead, reduction, and new overhead) simply and directly without extraneous information like the write operation overall time which is tangential to the article. If I said they reduced write overhead from 9ms to 1ms you'd have no clue what that meant in relation to the overall write operation. I'd have to include additional information about the write operation time and then either do math to arrive at the same percentages in the original post or leave the reader to do so.

      While it's fun to bash on editors, you're the one who needs a clue in this case.

      --
      You can get rich if you own a politician, but you have to be rich to buy one in the first place.
  9. Re:Limited number of writes by sexconker · · Score: 1

    Intel has numbers. But they're not sharing. They're still promising to ship the NVDIMM Xpoint modules "soon".
    Micron has numbers. But they're not sharing. Oh, and they're doubling down on DRAM manufacturing. They're not exactly going full steam ahead with Xpoint. I wonder why?

  10. Re:Security Q: Will This Leak Info? by TechyImmigrant · · Score: 1

    >But will this technique leak information about the contents of other XPoint memory addresses?

    It will open up interesting attack vectors, yes.

    1) If the information capacity of the checksum is less than the data being checksummed, you will be able to find collisions and maybe use this to cause targeted data corruption.
    2) Any 'lazy/speculative/delayed' execution has turned out to be a side channel vector in recent years.
    3) If CRCs are used instead of cryptographic hashes, then targeted data modification can yield checksum collisions with presumably unintended consequences.

    --
    I should use this sig to advertise my book ISBN-13 : 978-1501515132.