From: Rick van Rein <rick@groengemak.nl>
To: Andi Kleen <andi@firstfloor.org>,
daniel.blueman@gmail.com, david@lang.hm
Cc: Rick van Rein <rick@groengemak.nl>, linux-kernel@vger.kernel.org
Subject: Re: Future Linux on Bistable Storage
Date: Mon, 2 Jun 2008 21:10:27 +0000 [thread overview]
Message-ID: <20080602211027.GB18415@phantom.vanrein.org> (raw)
In-Reply-To: <87prqzvc17.fsf@basil.nowhere.org>
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
next prev parent reply other threads:[~2008-06-02 21:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-02 12:59 Rick van Rein
2008-06-02 17:02 ` david
2008-06-04 1:14 ` Jared Hulbert
2008-06-02 19:30 ` Daniel Barkalow
2008-06-02 20:04 ` Andi Kleen
2008-06-02 21:10 ` Rick van Rein [this message]
2008-06-03 0:51 ` Andi Kleen
2008-06-03 14:27 ` Stefan Richter
2008-06-03 16:12 ` Pavel Machek
2008-06-02 18:28 Daniel J Blueman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080602211027.GB18415@phantom.vanrein.org \
--to=rick@groengemak.nl \
--cc=andi@firstfloor.org \
--cc=daniel.blueman@gmail.com \
--cc=david@lang.hm \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®