Of course theres a long history of "multiple interface" drives which are always ugly hacks that turn up as rare collectors items and examples of boondoggle.
Y'know that eventually we'll be running everything off Intel's Optane non-volatile RAM: we won't have block-addressable storage anymore, everything will be directly byte-addressable. All of the storage abstractions that have popped-up over the past decades (tracks, heads, cylinders, ew, block-addressing, unnecessarily large block sizes, etc) will be obsolete because we'll already have perfect-storage.
It's not quite DASD, but it's much better.
"true" Optane hasn't taken over the scene because, to my knowledge, there's no commercially supported OS that's built around a unified memory model (heck, why not have a single memory-space?) for both storage and memory.
We can't even write software that can just reanimate itself from a process image that would be automagically persisted in the unified storage model. We've got a long way to go before we'll see operating systems and applications that take advantage of it.
(Of course, getting those chunks down to cache line sizes does open up a lot of possibilities...)
Also, RAM "block size" is 64B, while for flash its more like 4kB. CPU cache will "deblock" the 64B blocks, but it can't efficiently do it for 4kB ones.
And then there's the speed. Does replacing PCIe with a memory bus actually make a performance difference that's measurable given flash latency?
Also known as a bank. The transfer itself is 64 bytes at a time (burst length 8 for DDR4 x 64 bit channel). But internally, the RAS (row address strobe) is the access of note.
[0]: Zen3 does it for sure, but I think I also saw it somewhere else.
"row" buffer locality is relatively important for energy efficiency, and can account for about a 2x factor in the DRAM's power consumption. Each rank has 4 bank groups of 4 banks each, with the frequency of "activate" commands to banks in the same group being restricted more severely than to separate bank groups. A rank is just a set of chips who's command/address lines are in parallel, and who's data lines are combined to get up to the typical 64/72 bits of a channel. A single chip is just 4, 8, or 16bit wide. A channel can have typically between IIRC 1 and 12 ranks, which are selected with separate chip select lines the controller uses to select which rank the contents of the command/address bus are meant for.
Also, "activate" and "precharge" take about as long (most JEDEC standard timings have literally the same number is cycles for these 3 timings (also known as the "primary" timings)) as the delay between selecting the "column" in a "row" buffer, and the corresponding data bits flowing over the data bus (for reads and writes there may iirc be a one-cycle difference due to sequencing and data buffers between the DDR data bus and the serdes that adapts the nominal 8-long bursts at DDR speeds to parallel accesses to the "row" buffer).
With JEDEC timings for e.g. DDR4-3200AA being 22-22-22 CL-tRCD-tRP ("column" address-to-data delay; "row"-to-"column" address delay; "precharge"-to-"activate" delay), and the burst length being 4 DDR cycles, this is far from random access.
In fact, within a bank, and even neglecting limits on activate frequency (as I'm too lazy to figure out if you can hit them when using just a single bank), with assumed-infinite many "rows" and thus zero "row" locality for random accesses, as well as perfect pipelining and ignoring the relatively rare "precharge"/"activate" pairs at the end of a 1024-columns-wide "row":
Streaming accesses would take 4 cycles per read/write of a 64B cacheline (assuming a 64bit (72 with normal SECDED ECC) DIMM; is less bits, the cacheline would be narrower), archiving 3200 Mbit/s per data pin. Random accesses would take 22+22+22=66 cycles per read/write, archiving 193 ³¹/₃₃ Mbit/s per data pin.
So random accesses are just 6 ²/₃₃ % efficient in the worst case and assuming simplified pathological conditions. In practice, you have 16 banks to schedule your request queue over, and often have multiple ranks (AFAIK typically one rank per 4/8/16GiB on client (max 4 per channel on client, 2 optimal, with 1 having not enough banks and 3-4 limiting clock speeds due to limited transmitter power) and low-capacity servers; one rank per 16-32GiB on high-capacity servers).
There is a slight delay penalty for switching between ranks, iirc most notable when reading from multiple ones directly in sequence or possibly when reading from one and subsequently writing to another (both are pretty bad, but I don't recall which one typically has more stall cycles between transmissions; iirc it's like around 3 cycles (=6 bits due to DDR; close to one wasted burst)).
Wait, are the underlying hardware access size for memory bigger than the default Linux page size (4kb)? Wouldn't that introduce needless inefficiencies?
Can false sharing happen between different pages if they happen to be in the same row?
In practice, the only thing DDR4 banks do is make prefetching an important strategy, thus making sequential performance for DDR4 incredible.
A fact already known to high performance programmers. Accessing byte 65 after byte 64 is much more efficient than accessing byte 9001.
https://faculty-web.msoe.edu/johnsontimoj/EE4980/files4980/m...
diagrams on pages 4-7.
Doesn't OS/400 work that way? (Of course then there is the question to which degree "commercially" should imply "readily open to third-party software and hardware vendors")
> IBM's design of the single-level storage was originally conceived and pioneered by Frank Soltis and Glenn Henry in the late 1970s as a way to build a transitional implementation to computers with 100% solid state memory. The thinking at the time was that disk drives would become obsolete, and would be replaced entirely with some form of solid state memory.
...so they were literally 50-60 (maybe 70-80 at this rate) years ahead of their time.
Suffice it to say that it was promising while it was under development, but Intel neglected to factor in just how much flash vendors would improve performance and reduce cost per bit.
https://www.rambus.com/memory-and-interfaces/server-dimm-chi...
There's a lot of simplifications you can use knowing everything is a world of 512 byte/8k blocks.
Everything that's a linked list of blocks would suddenly be lists of "start and offset" instead, because you might have a file was fragmented as "1Mb at offset A, 32 bytes at offset B, and 5Mb at offset C". You'd likely need some tradeoffs for minimum fragment sizes to avoid a file sharding into a million 32-byte fragments and requiring a huge number of distinct reads to load, and maximum sizes that would be manageable without overloading the recipient device's buffer.
Rumors seem to be that Oxide Computers is trying to make an OS to control many of these but I suspect the end result will be treating the case as a heterogeneous cluster. It's possible that these will continue acting cooperatively rather than anyone being under the misapprehension that they're actually 'in charge', but perhaps a different division of labor will give us some cool benefits.
Would still love to see SQLite or Postgres running directly on a storage subsystem.
I'm not sure what Oxide is doing, but creating an OS to replace the firmware on all kinds of 3rd party devices sounds, well, quite quixotic. I'd guess it's more like a common OS for the firmware of their own hardware (rack controllers and whatnot).
You could say the same about device drivers in Linux. It was a very long process that required many, many hands. It took a long time even to cover all of the common devices let alone the more obscure ones.