Wednesday | 9 July, 2008
Computerworld

Kernel space: How to use a terabyte of RAM
An experimental new design for Linux's virtual memory system would turn a large amount of system RAM into a fast RAM disk with automatic sync to magnetic media
Jonathan Corbet (LinuxWorld) 19/03/2008 11:15:26

Computerworld Buyer's Guide - Vendors Matched to this Article
Additional Resources
Executive Guides
Whitepapers
Zones
Zone logoZones provide focussed content from Computerworld and leading technology partners.

Newsletter Subscription

Sign up for our Computerworld newsletters!
Computerworld's twice-daily news service keeps you in touch with the latest, most important headlines from Australia and around the world.
Keep up with the latest virtualization technologies, products, news and features.
RSS Feeds

We have not yet reached a point where systems - even high-end boxes - come with a terabyte of installed memory. But products like those from Violin Memory make it clear that the day is coming; one can buy a Violin box with 500GB in it now. So it seems worth asking the question: once one has spent the not inconsiderable sum to buy a box like that, what does one do with all that memory - especially now that the Firefox developers have gotten serious about fixing memory leaks? Perhaps it's time for some wild ideas. And there is no better source for such ideas than Daniel Philips, whose Ramback patch has stirred up a bit of discussion this week. The core idea behind Ramback is that all of that memory is turned into a ramdisk, but with a persistent device attached to it. In normal conditions, all application I/O involves only the ramdisk, and is, thus, quite fast ("Every little factor of 25 performance increase really helps."). In the background, the kernel worries about synchronizing data from the ramdisk onto permanent storage. But the synchronization process is mostly concerned with I/O performance, rather than providing guarantees about just when any given block will make it onto the disk platters.

Ramback thus differs from the normal block I/O caching done by the kernel in a number of ways. It keeps the entire device in memory, so that, in steady-state operation, applications need never encounter a disk I/O delay. Should an application call fsync(), the expected result (blocking until the data is written to physical media) will not happen. Filesystems take great care to order operations in a way that minimizes the risk of data loss in a crash; Ramback ignores all of that and writes data to physical media in whatever order it decides is best. As Daniel put it, the "most basic principle" of Ramback's design is:

[T]he backing store is not expected to represent a consistent filesystem state during normal operation. Only the ramdisk needs to maintain a consistent state, which I have taken care to ensure. You just need to believe in your battery, Linux and the hardware it runs on. Which of these do you mistrust?

Computerworld Buyer's Guide - Vendors Matched to this Article
More about Linux, Philips
Market Place

Computerworld Member Login


 

Beyond Virtualisation - The Roadmap to 2012

CIO Breakfast Briefing
8:30am - 10:30am

Brisbane | 22 July | Sofitel Brisbane
Sydney | 23 July | Four Seasons Hotel
Canberra | 24 July | The Hyatt

Attend and discover:

  • What happens after virtualisation
  • The benefits automation drives
  • When automated infrastructures will emerge
  • What the roadmap to 2012 looks like
  • How to deliver an automated architecture
  • How to maximise your investment in virtualisation
Whitepaper

Outsourcing the Mainframe

Today's CIOs are operating in a highly competitive environment. Discover how to drive down spending on maintenance and operations to free up capital for discretionary IT-business projects.

Enterprise IT Buyer's Guide
Find Technology Vendors Fast
 
Find vendors by name | Find by category
Sponsored Links