Re: Future Linux on Bistable Storage

Hello,

Thanks for your responses. You convinced me I/O initiatilisation cannot
be improved upon.

unless there has been a breakthrough that I haven't heard about (always
possible) I seriously doubt that this is the case.

Oh wait... I'm talking of upcoming technologies, not established ones!

the alternate technologies that I have heard about are either _far_ less
dense then DRAM (similar to static ram) or require erasing in blocks
(similar to flash).

NanoRAM for one sounds like it can achieve very high densities and high
speeds in coming years. A slideshow from a researcher gives numbers:

http://www.imechanica.org/files/Proposal-MNRAM.pdf

100 GHz speeds, 100 T/cm2 -- and it's all bistable so no power is consumed
to keep it going, as is a limitation with DRAM. With a cm2 of that I don't
think we'd care for a HDD or for DRAM anymore.

Perhaps one of the more key stepping stones here is execution in place
(XIP) support [...] Maybe [...] we should consider XIP-for-ramdisk
(rather than ROM/flash).

That's the sort of thing I was hoping to spark -- I hadn't seen XIP but
it does sound like a limited form of the kind of thing that would integrate
memory/disk into one large bowl of bits. Thanks for the pointer!

Anyway, from a mmap() perspective, we'd be logically merging the
filesystem and pagecache layers and losing a layer of physical
indirection.

Something like that... a smooth exchange between memory pages and disk
pages, where it would even be possible for a page to be part of both,
a bit like XIP indeed.

One major difference between disk and RAM is the tradeoffs between size,
speed, and price. It's highly unlikely that any one technology will ever
beat all others in both of the usage patterns which are normal for RAM and
disk in devices considered by their users to be "computers".

I beg to differ. If the numbers above are anything to go on, that is.
We have a tendency to think of DRAM as something that can grow without
bounds, but its power consumption and consequential dissipation due to
refreshing do limit it, for example when applied in a mobile device.

Refreshes occur ~1000 times a second for all cells in DRAM, AFAIK.
That's rather a lot of data being read and rewritten each second!
No wonder the chips heat up, and consequently cannot be stacked to
form a cubic memory structure.

I think current ramdisk code skips [buffering disk blocks].

That'd help, but I'm not sure the concepts of memory and ramdisk should
be kept separate if this architecture I am thinking of would come through.


You have helped to answer my question, whether Linux was ready for the
architecture that I talked about: it already contains seedlings for its
support, so it does not seem to conflict with Linux' major architecture.
That's good news!


Thanks,

Rick van Rein
GroenGemak
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: making a removable SSD drive nonremovable
    ... Putting in a FLASH based memory will make ... Are you certain that it's not battery backed RAM? ... I was talking about DRAM. ...
    (microsoft.public.windowsxp.hardware)
  • Re: Different Implementations of VLIW .
    ... | did they cost anywhere close to $25,000 (not even after adding memory ... Note that at the $5000/system price we were getting almost *no* margin ... I don't know whether you're talking "OEM cost" or "retail ... If you ignore our artificially low initial DRAM sales ...
    (comp.arch)
  • Re: AMD to leave x86 behind?
    ... >> When a memory request arrives at a memory controller, ... When there is no other earlier requests to a given cache ... >> The PROBE responses and the DRAM data meet back at the originating Node ...
    (comp.arch)
  • Re: Memory controller state of the art?
    ... > don't know how you'd build a tag structure to manage such a cache. ... I favor a OS-managed memory. ... > close to price parity with the commodity DRAM stuff, ... buffer chip on the same board as more conventional DRAMs and ...
    (comp.arch)
  • Re: More Cache to the Chip
    ... L1-N SRAM cache backed by LN+1 DRAM caches that have been used for ... You have a small fast memory plus a big slow memory. ... III to 533MHz speed with 15ns bank access, ...
    (comp.arch)