Re: Future Linux on Bistable Storage

On Mon, 2 Jun 2008, Rick van Rein wrote:

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.

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".


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

CONFIG_SWAP=n

* buffering disk blocks

I think current ramdisk code skips it.

* lazy loading of programs from disk to RAM
* mapping and unmapping disk onto RAM

You still need the distinction between what's in a process's address space
and what's in the filesystem, in order to have a system that feels like a
computer.

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?

Userspace setup stuff hugely dominates boot time. Some drivers, and it's
not known which, only successfully initialize on the assumption that some
other drivers are not initializing hardware at the same time. This has
been tried, and it (a) had some hard-to-track bugs and (b) didn't help
enough to be worth dealing with.

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.

Writing all of RAM to disk burns more power than powering RAM for several
minutes, even assuming you don't have to spin up the hard drive. For that
matter, restarting the system will power up all of the devices on the bus
that you've shut down because you're not using them.

It'd be an easy way to save some trees :)

You have a wood-fired power plant?

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.

In general, any time you switch drivers or kernel versions, you'll want to
have the device return all of its registers to a default state and take it
through an initialization process. For that matter, even if the memory
keeps its state, on power failure some calcuations will have been done and
some will not, so the resulting storage will be in some unknown state and
need to be reinitialized from storage that wasn't changing.

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.

It's likely that the power cost of getting a consistant state to the
bistable memory will be more than the idle power required for a couple of
seconds.

-Daniel
*This .sig left intentionally blabk*
--
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: disk spin down with lots of log files
    ... I want to spin the disk down to save power. ... activity writing log files to the disk, ... I have lots of RAM.) ...
    (comp.os.linux.setup)
  • Re: disk spin down with lots of log files
    ... I want to spin the disk down to save power. ... activity writing log files to the disk, ... I have lots of RAM.) ...
    (comp.os.linux.setup)
  • Re: Slow shutdowns for Illustrator, Photoshop Elements, Acrobat?
    ... You can install the "Deep Sleep" widget to set which kind of ... When you suspend to disk only (instead the default ... safe sleep which writes the RAM to disk and then suspends to RAM to be ... But my iBook battery would last for weeks even in the relatively power ...
    (comp.sys.mac.system)
  • Re: Why Do embedded processors have more Flash than RAM
    ... For an embedded computer just think of Flash as disk and there is ... loading it in RAM as you would from a disk. ... what you want to keep around between power cycles, ...
    (comp.arch.embedded)
  • Re: [ANNOUNCE] Ramback: faster than a speeding bullet
    ... window during which UPS power must remain available if power goes out, ... they aren't arguing that the embedded solutions are more safe becouse they don't use linux. ... the reason why battery backed ram on a raid card is safer than a UPS on a general purpose machine is becouse the battery backed ram is static ram, while the ram in your system is dynamid ram. ...
    (Linux-Kernel)