From: Rick van Rein <rick@groengemak.nl>
To: linux-kernel@vger.kernel.org
Subject: Future Linux on Bistable Storage
Date: Mon, 2 Jun 2008 12:59:04 +0000 [thread overview]
Message-ID: <20080602125904.GA15129@phantom.vanrein.org> (raw)
Hello,
Future generations of Linux are likely to run on machines with non-volatile
memories based on bistable technologies. This will save the energy of DRAM
refresh cycles and avoid the mechanical problems related to hard disks. The
result is probably a computer with no distinction between disk and RAM.
Such computer architectures can conserve a lot of energy, as it is very
simple to suspend and resume them: no data loss means no time needed to
resume the system -- except perhaps for I/O initialisation. Conserving
energy means (1) having more fun|hours per kg of batteries, and (2) saving
the planet.
I wonder inhowfar Linux is (already) capable of dealing with such hardware.
Several core concepts suddenly become meaningless if disk and RAM are merged
into one storage device:
* swapping out data
* lazy loading of programs from disk to RAM
* buffering disk blocks
* mapping and unmapping disk onto RAM
Regarding I/O init: Current Linux boots while initiating one device at a
time. Some degree of serialism must exist, but after scanning a bus would
it not be possible to fork threads to initiate each of the devices found
on it? Am I overlooking details or could this be a useful change?
If it is possible, it would make Linux _much_ quicker to boot (also on
current hardware), and it could even make it acceptable to do a suspend
after a _very_ short time (say, a minute) of non-activity. It'd be an
easy way to save some trees :)
In the long run, it seems fair to assume that all devices, including
processors, would use non-volatile buffers based on one of the bistable
semiconductor devices currently being developed; but I would not be
surprised if at first we will be working with computers that have older
parts mixed in; boards that still forget their registers when switched off.
But in the end I expect the entire system to switch itself off in between
every two keystrokes (!) simply because loosing no data anywhere in the
system means being able to resume operations at the next whim/interrupt.
I have seen Linux make quite impressive changes to its fundamental
architecture. Could this be the Next Big Challenge to the flexibility
of our favourite OS? What would have to change to make it happen, and
is it doable?
Finally, a few background links:
* WikiPedia on Non-volatile memory; especially review the "Upcoming"
technologies FeRAM, MRAM, NRAM, PRAM, and so on:
http://en.wikipedia.org/wiki/Non-volatile_memory
* "Towards Zero-power Computing" at GroenGemak:
http://groengemak.nl/en/article/2008-05-19-10-05.toekomst-computer.html
Yours truly,
Rick van Rein
GroenGemak
http://groengemak.nl/
next reply other threads:[~2008-06-02 13:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-02 12:59 Rick van Rein [this message]
2008-06-02 17:02 ` Future Linux on Bistable Storage 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
2008-06-03 0:51 ` Andi Kleen
2008-06-03 14:27 ` Stefan Richter
2008-06-03 16:12 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
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=20080602125904.GA15129@phantom.vanrein.org \
--to=rick@groengemak.nl \
--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