Gentoo Wiki





Every few weeks a scheme is floated around on the forums to accelerate system performance somehow using a ramdisk to speed access to certain data. This page is meant as a comprehensive review of the theory behind such strategies to help the reader weigh the benefits against the costs of a particular scheme.


Ramdisk performance enhancement techniques tend to be based upon one or more of three strategies: using RAM to cache disk reads, using RAM to cache disk writes, and using a ramdisk to decrease system bootup speed, although the latter is usually a special case of the first two. Read caching is the most interesting case, and as it is most often attempted and offers the most straightforward opportunity for performance improvement, it will be the primary focus of this article.

Read Caching

It is tempting and sometimes effective to use a ramdisk to cache disk reads. An application which starts slowly and is accompanied by lots of audible hard drive activity and/or HDD-LED activity can often stand to benefit from this strategy. The normal procedure is for program and library code as well as any shared data (themed graphics, sound effects, etc.) to be copied from disk to system memory for execution and use immediately upon invocation of a program. The telltale hard drive noise which typically accompanies this delay between invocation and application launch illustrates this slow disk copy. The ideal optimization on this process would be for all required data to already be present in system RAM upon invocation, obviating slow disk copy activity and minimizing the startup time of the program to the time required for computations related to initialization.

OS-level read caching

A generalized approach is taken by the operating system's file caching subsystem; in Linux, the VFS Virtual Filesystem layer takes proactive responsibility for making use of unused physical memory and idle mass storage channels to load files into memory which it anticipates will be needed in the future. Leaving physical RAM idle with useless data in it is wasteful, and there is virtually no performance penalty when space used for cache is needed for other data as the cache is usually a redundant copy of something already on the disk and can therefore be safely discarded. The prediction algorithm is reasonably effective, as it is based on time-tested principles of cache locality, however in specific cases an informed administrator can improve upon the caching system's prediction by forcing choice files into cache. This is the goal of strategies aimed at caching disk reads: to override the system's decisions about what data is likely to be used in the future.

The typical prediction strategy assumes that data near currently used data is much more likely to be needed in the future. This truth should be relatively obvious; a user with a large text file or database open is more likely to scroll up or down and require an additional megabyte of that file than any other particular megabyte on the hard drive. Note that although a similar assumption can be made about executable program code, the mechanism which loads code into memory for execution is much more complicated; in most situations, the entirety of a program is loaded together upon invocation. Once again, this mechanism is a Good Thing, and it works as well as it can without specific knowledge about how you use your computer.

Optimization considerations

Performance schemes based around read caching typically involve placing one or more programs (along with required support files and libraries) or even entire filesystem hierarchies (/bin, /usr/bin, /lib, /usr/lib, etc) into a ramdisk in order to force them into system memory for quick access. There are several considerations in attempting such a scheme.

Less is more

In the best case, placing a megabyte worth of information into system RAM to speed access would reduce the amount of available system RAM by one megabyte. This sort of efficiency is reasonably easy to achieve in the real world using tmpfs. The trade-off (no matter what filesystem/ramdisk is used) is that in addition to reducing your available system memory by an amount equivalent to the size of all files precached in this manner, the unallocated memory available to the caching subsystem for caching other files is reduced. By using a substantial amount of system memory to precache many executables and libraries, you substantially impair the ability of the caching subsystem to accelerate access to all other data on your disks.

Filesystem implementation

The choice of how to implement such a scheme can have a substantial impact on its memory footprint. A conventional ramdisk approach presents a section of system memory as a block device which can be formatted using a standard filesystem like ext2/3 or reiserfs. This is less than ideal because in most cases, files must still be copied off the "disk" into RAM for use, doubling the effective memory footprint of each file in use. While it's nice to be able to think of your ramdisk as a disk like any other, many of the benefits of storing data in RAM are lost if you treat the ramdisk as a generic block device. In an extreme case, you may even risk caching information in your ramdisk! This problem can be partially solved by using an eXecute In Place (XIP) capable filesystem which supports running executable code straight from any block device which is addressable as part of system memory. ext2 supports this operation in recent kernels. A better solution still is tmpfs. tmpfs is a brilliant extension to the system's existing cache architecture which stores files in cache. It essentially works by caching a file that is copied into the filesystem and marking it "dirty" such that the caching subsystem never discards it to free memory unless it is first deleted from the filesystem. Among the advantages of tmpfs are that it sizes dynamically, that it has none of the overhead imposed by formatting RAM with a traditional filesystem, and that it is built into every 2.6 series kernel automatically.


An effective strategy for improving read performance for certain data can therefore be summarized as follows. In certain cases, the system administrator can be confident that his or her judgment about what data is worth caching into RAM is better than the system's and that the difference is worth the cost in memory available to software and cache for other data. In these cases, selected applications and data can be copied to and subsequently accessed from an appropriate RAM-based filesystem, typically tmpfs, in order that future accesses will not require any loading from mass storage.

Write Caching

An alternative or sometimes complementary strategy to caching disk reads using a ramdisk is caching writes. Fortunately, caching disk writes is much simpler than caching reads as it does not require prediction, and the VFS caching subsystem as discussed above handles write caching very effectively.

Temporary files

One small exception is in the case of temporary data which does not need to be written to disk at all. Although this does not really address write caching per se, it can be a good reason to store files in RAM. tmpfs is again the implementation of choice due to its dynamic sizing and low overhead. A tmpfs mount can be specified in fstab and used for the /tmp hierarchy. Note that unless you have way, way more RAM than you know what to do with, only small-scale temporary storage in RAM is feasible. The contents of, for example, /var/tmp/portage, would fill your system memory in a heartbeat.

Startup Optimization

This article is still a Stub. You can help Gentoo-Wiki by expanding it.

Retrieved from ""

Last modified: Mon, 08 Sep 2008 21:16:00 +0000 Hits: 550