Flameman/mtd

Graphic cards contain a lot of very fast RAM, typically between 64 and 512 MB. It's possible to use it as swap space, or even as RAM disk.

Good Hardware

 * ATI Radeon 9500 Pro

Good candidates

 * ATI Radeon 9250 256MB DVI/VGA/TV PC scheda video PCI (not tested yet)

Kernel Configuration
To use the graphic (and possibly any other) card's memory, it needs to be mapped by the kernel. By default only the system RAM is considered as usable RAM, to access memory from the PCI address space one needs a driver which registers them. In 2.6 kernels this driver is called Memory Technology Device (MTD). You need to enable this and some other key features in your kernel:

Kernel|Enable MTD kernel features Device Drivers --->  Memory Technology Device (MTD) support --->  Direct char device access to MTD devices  Common interface to block layer for MTD 'translation layers  Caching block device access to MTD devices Self-contained MTD device drivers --->  Physical system RAM

You can compile them as modules or built-in drivers, it works either way.

Finding the memory
Now let's search for the video memory in the PCI space. The easiest way is to use


 * lspci (sys-apps/pciutils)

Start with looking up your graphics card: lspci | grep VGA

an example output would be: 02:00.0 VGA compatible controller: ATI Technologies Inc R300 AD [Radeon 9500 Pro] That's the graphics card. now we need to use lspci again to check the card for more details.

To to this we tell lspci to be verbose when checking the PCI slot 02:00.0, as the previous lspci output indicated the graphics card sits there:

lspci -vvv -s 02:00.0 0000:02:00.0 VGA compatible controller: ATI Technologies Inc R300 AD [Radeon 9500 Pro] (prog-if 00 [VGA]) Subsystem: PC Partner Limited: Unknown device 7c07 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- <PERR- Latency: 32 (2000ns min), cache line size 08 Interrupt: pin A routed to IRQ 255 Region 0: Memory at d8000000 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at b000 [size=256] Region 2: Memory at e9000000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at e8000000 [disabled] [size=128K] Capabilities: [58] AGP version 3.0 Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8 Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW- Rate= Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- What we need to look for is the prefetchable memory region, Region 0. The start of the memory space is 0xd8000000, a 32 bit hex value.

Mapping the memory
To actually access the memory from PCI space, you need to tell the MTD driver where it starts and how much of it you want to allocate.

Loading SLRAM module
 * 1) Region 0 starts at 0xd8000000, leave 4 MB ram for the VGA, so add 4*1024*1024 to it
 * 2) which is 0x00400000 in hex, 32 bit. This means: 0xd8400000 will be the starting position.
 * 3) Now, to use the other 124 MB, the easiest way is to tell the offset value.
 * 4) The third parameter's leading + means that we are telling the offset,
 * 5) not the actual region's ending address. 124 MB is 0x7c00000 in hex, 32 bit.

modprobe slram map=VRAM,0xd8400000,+0x7c00000

Loading PHRAM module
 * 1) Loading with PHRAM module is very similar to SLRAM module, except that it uses a "length"
 * 2) parameter by default rather than an "end offset".

modprobe phram phram=VRAM,0xd8400000,0x7c00000
 * 1) This does the same thing as the SLRAM module above

modprobe phram phram=VRAM,0xd8400000,124Mi
 * 1) This is also the same (and easier to read)

or if you compiled it as built-in, change your kernel command line to contain this: Adding SLRAM configuration to the kernel command line
 * 1) Now the first parameter is the device which will be mapped.
 * 2) Other parameters share the same meaning shown above, in the module version.
 * 3) Please reboot your computer, to take it effect.

slram=mtd0,0xd8400000,+0x7c00000

What you should see in dmesg is: slram: devname = mtd0 slram: devstart = 0xd8400000 slram: devlength = +0x7c00000 slram: devname=mtd0, devstart=0xd8400000, devlength=0x7c00000 slram: Registered device mtd0 from 3543040KiB to 3670016KiB slram: Mapped from 0xe0880000 to 0xe8480000

Also, to be sure, check /proc/mtd dev:   size   erasesize  name mtd0: 07c00000 00004000 "mtd0"

Creating the mtd devices
After you have the support in the kernel and all the required data, you need way to access the memory. Time for creating the devices!

If you have udev just modprobe mtdchar and modprobe mtdblock and hald will create device files for you automatically. The mknod magic
 * 1) Create the character device. MTD will use and map this, so it's not used by
 * 2) userspace programs but is vital for MTD to function.
 * 3) If "Direct char device access to MTD devices" was compiled as module, run modprobe first: modprobe mtdchar

mknod /dev/mtd0 c 90 0


 * 1) Create the block device. This will be used. Requires the "Caching block device access to
 * 2) MTD devices" kernel feautre, if compiled as module, first run: modprobe mtdblock

mknod /dev/mtdblock0 b 31 0

Using it
Now, you can either use it as a RAM Disk, or as swap. Either way, you need to create a FS on it, I'll go with the swap way. Creating swap mkswap /dev/mtdblock0 swapon /dev/mtdblock0 }}

This will create the swap structure in the video card's RAM, and also activate it as system swap. To specify the priority (which swap source will be used first in the swap list), use swapon's switch, -p X where X is a number between 0..32767, the higher the number, the higher the priority. {{Code|Specified priority for swap

swapon /dev/mtdblock0 -p 10

Without specifying priority, the next lowest will be used. Also, this can be added to the fstab, so you won't need to manually add this after every boot: {{Code|/etc/fstab

/dev/mtdblock0                 none            swap            sw,pri=10
 * 1)                                                        

In the options field, the pri= is the same as swapon's -p switch. Please read the troubleshooting section, before closing this page.

Be warned
It's nice to have fast swap or RAM disk on your home computer but be warned, if a binary driver is loaded for X, it may freeze the whole system or create graphical glitches. Usually there is no way to tell the driver how much memory could be used, so it won't know the upper limit. However, the VESA driver can be used because it provides the possibility to set the video RAM size.

So, Direct Rendering or fast swap. Your choice.

Unlike motherboard RAM and hard drives, there aren't any known video cards that have ECC memory. This may not be a big deal for graphics rendering, but you definitely don't want to put critical data in it or use this feature on servers.

Troubleshooting

 * Q: mkswap/mkfs.whatever succeeds, but I can't swapon/mount it! Also it reads 0xff bytes! What to do now?
 * A: You have to set the BIOS setting, AGP Aperture Size to at least or equal to your video RAM. Most people say it's better to set it to the half of your system RAM/video RAM size, but it does nothing just limits the BIOS' capability to map from PCI address space.
 * A: It is also possible that you are using wrong address/offset values. Double-check that you are using the 'prefetchable' space.
 * A: Make sure the videocard that contains the memory has a driver loaded.
 * A: Make sure the videocard that contains the memory has a driver loaded.


 * Q: I have shut down my computer and during the next boot I see it couldn't add /dev/mtdblock0 as swap! What did go wrong?
 * A: It's trivial but at first time everyone is surprised: RAM will lose its contents if not powered. Solution: mkswap again!
 * A: It's trivial but at first time everyone is surprised: RAM will lose its contents if not powered. Solution: mkswap again!


 * Q: The kernel tells me: slram: ioremap failed. What is this?
 * A: You forgot to add + before the actual value in the third parameter, so it's not considered as offset code but an actual PCI address. Prefix with +, or calculate the exact ending location.
 * A: You forgot to add + before the actual value in the third parameter, so it's not considered as offset code but an actual PCI address. Prefix with +, or calculate the exact ending location.


 * Q: There is no /dev/mtd0 and/or /dev/mtdblock0 device.
 * A: Read the 'mknod magic' box.
 * A: Read the 'mknod magic' box.


 * Q: I have enabled Highmem support in the kernel and now slram complains something about vmalloc in dmesg. I can't access the device.
 * A: Try appending vmalloc=nM to the kernel parameters, with n something like 256 or higher if needed. The default is 128
 * A: Try appending vmalloc=nM to the kernel parameters, with n something like 256 or higher if needed. The default is 128


 * Q: Does this work with onboard display with side-port memory?
 * A: Recent AMD/ATI Integrated Graphics Processor (IGP) can be equipped with dedicated memory, the so-called side-port memory. The IGP, together with the side-port memory, is disabled by default when you are using an independent graphics card. You can enable the IGP by enabling the SurroundView in the BIOS, this will also enable the side-port memory. Then you can configure it as a MTD.
 * A: Recent AMD/ATI Integrated Graphics Processor (IGP) can be equipped with dedicated memory, the so-called side-port memory. The IGP, together with the side-port memory, is disabled by default when you are using an independent graphics card. You can enable the IGP by enabling the SurroundView in the BIOS, this will also enable the side-port memory. Then you can configure it as a MTD.

full article
This article describes the required steps to convert a portion of RAM into swap space. We examine some of the reasons you might want to do this, including that using RAM as swap can be many times less expensive than using most fast solid state storage solutions. Additionally, it can be a lot easier to purchase and implement. Read on for the details.

Say you have a Linux system, and you are noticing latency. Then you find that the slowness is from the time taken to swap programs back into main memory. Say you have 512 MB of RAM and a 1 GB swap partition on hard disk. Now, what if you could afford to remedy this with a solid state storage device of GB size, and you could just plug it into your computer in an already available slot or connector? This would be used to replace the swap partition. If it were in a PCI connector it could have a maximum transfer rate of perhaps 133 MBytes/sec, which is a lot faster than an IDE drive, for sustained data transfers. Plus, the seek time would be a lot less than a millisecond. If this weren't too expensive, you might go for it? There are some multi-GB rack mount units available for tens of thousands of dollars that fulfill this, and they would reduce the swap in (and out) latency to almost the point where it would not be noticeable.

However, if almost the same thing could be accomplished for a lot less money, and have a much higher data transfer rate, that would be even better. So, if you happened to have 512 MB of memory using a single stick of DDR in a motherboard that has 4 slots, you could get another two 512 MB sticks (fulfilling the 2x RAM guideline for swap) and plug them in, and use the procedure in this article to use them as swap space. Then you would have the same memory situation you have now (if you were using 1 GB swap partition), but you will hardly notice when something needs to be swapped back in. Looking at it this way, you can have an approximately $200 (circa 2004) silicon hard drive with a very fast interface connection (PC2100 DDR has a 2100 MBytes/sec transfer rate, a lot faster than the PCI bus). $200 is a lot less than $10,000, and 2100 MBytes/sec is a lot faster than the PCI bus. The only negatives are that it sounds like a crazy idea to use valuable RAM as swap, and this has not been fully tested.

This information is provided so that people can easily (hopefully) set their computers to use a portion of their RAM, real physical memory, as swap space, thus making it possible to have about the fastest swap drive available at the least cost. These steps have been tried on my Red Hat (9 and FC1) and Debian computers. My results were 30 seconds to swap in a large application with hard disk swap verses 0.5 seconds using either swap in RAM or 0.75 seconds using no swap.

If you are using Linux as a workstation, and are experiencing its characteristic slowness in switching applications (sometimes making the computer seem to have a video adapter problem due to the slowness of painting the screen) then you might seriously consider using a portion of your RAM as swap, and perhaps turning off the swap partition on the hard drive.

It does seem, in my testing so far, that there should be at least 512 MB of RAM installed for this to help in the 2.4 and later kernels. From what I see in my limited testing of 2.6 kernels, this might not be as relevant in that case, because you can use the swappiness parameter. I have not tested this yet on 2.6.

Now, you could just shut off the swap partition (which is a lot easier):

(only do this if you have a fair amount of RAM, like at least 512 MB in RH9. I first tried this in September 2003.)

Bring up a terminal/console and log in as root: Use the command:

swapon -s

to see on which partition the swap currently resides, and how much of it is in use. Then use:

free -mt

to see how much memory is in caches and buffers. If the sum of the memory in caches and buffers is at least 10% more than that in the swap, you should be able to successfully execute the command

swapoff /dev/hdxx

Where xx is the designation of the swap partition(s) obtained above in the swapon -s results. This might take a minute, and actually it is best done just after boot up, before anything is in the swap partition, but it can be done later, when heavy swapping is slowing your system down. But the condition that the swap has to be able to fit back into the memory used by the cache and buffers is a solid requirement. If there is not enough space, the system crashes. If you have important data, don't try this until it is saved.

Now that swap is off, things should speed up considerably. When I ran with this configuration (no swap and 512 MB RAM) it seemed to flicker and be a little erratic, but it didn't crash. I suspect it was experiencing the paging storms I have seen discussed in the kerneltrap.org site. But this is the simplest test. If you have a GB of physical memory you will have to be using a real memory hog application, or hundreds of processes up at the same time (perhaps more than 300) to run into a problem. But if you had 256 MB of physical memory and 512 MB of swap you would run out of memory sooner and have memory problems too.

If a machine had 256 MB of RAM and a 256 MB swap hard drive partition, and later this was converted to 512 MB of RAM, with 256 MB of that as a swap file, and the hard drive swap turned off, will there be more application kills in the swap ram case or the hard drive swap case, all other things being equal? It would seem that they both would run out of memory, requiring a user mode process to be killed, at the same point. Again, this is something that can be tested, and tested more easily using these steps to make swap RAM.

However, using part of memory as swap space seems to allow the computer to run more smoothly, and since the virtual memory system is written expecting swap, and is optimised for it, why not just try it and see what happens.

Here is the thinking. If you have a system with 128 MB of RAM (like an old laptop) and a swap partition of 256 MB, with the more current Linux versions, the memory and swap get fairly full after a couple days or hours depending on your use. Then when the computer is used interactively, it will be spending a lot of time swapping and may take 30 seconds or more to get a swapped out application back on the screen.

I have seen this swap thrashing phenomenon on my 400 MHz laptop with 128 MB and FC1. And with only that much RAM, I can't do much about it. I did notice that changing the kswapd parameters from 512 32 8 to 512 32 64 seemed to make the swapping somewhat faster, and I haven't had any trouble with overloading the request que yet, but a server might, or might not.

To use RAM as swap, quite a few steps are necessary.

Here is a procedure that works for me.

1) Determine the size of your default ramdisks in your distribution. This has been 4 MB in the past, but I have seen 96 MB as the default. If 96 MB is the default you may not need to change it.

For example, if your RAM is 1 GB, but your default ramdisk size is 4 MB, and the default number of ramdisks is 20 (as in RH FC1), even if you used all your 4 MB ramdisks as swap that would only be 80 MB. If we are going to blindy follow the "one to two times the physical RAM as swap" rule, we need to use 512 MB for a 1 GB physical RAM where we are using only half of that as our "physical RAM". So we would have to increase the default ramdisk_size to at least 25.6 MB each. But they should be larger so you have to use less of them to aviod possible problems if some of the ramdisks are already linked and used for something else. Say we decide to use 4 ramdisks to contain the 512 MB swap. Each one will have to be 128 MB, so use the command:

ramdisk_size = 131072

(for example, this doesn't seem to have to be exact)

This command is added to the kernel line in grub, and in to the kernel subsection(s) of LILO. Make sure it works by testing the size of your ramdisks as described later.

Now that you (hopefully) have an appropriately sized default ramdisk, it has to be prepared.

2) Each ramdisk needs a directory on which to be mounted. I used /swapram/rdxx (where xx is the number of the drive). For this example, using 4 ramdisks, they would be:

mkdir /swapram mkdir /swapram/rd10 mkdir /swapram/rd11 mkdir /swapram/rd12 mkdir /swapram/rd13

Now you have four mount points for the swap ram at a place where you can probably find them later. This step needs to be done only once. All commands past this need to be used whenever you want to use swapram. You can make a script file for this purpose.

The ramdisks I chose to use were ram10, ram11, ram12, and ram13. These already exist in the /dev directory.

3) Next comes making the filesystems on the ramdisks we are going to use.

mke2fs /dev/ram10 mke2fs /dev/ram11 mke2fs /dev/ram12 mke2fs /dev/ram13

4) Now they need to be mounted:

mount -t ext2 /dev/ram10 /swapram/rd10 mount -t ext2 /dev/ram11 /swapram/rd11 mount -t ext2 /dev/ram12 /swapram/rd12 mount -t ext2 /dev/ram13 /swapram/rd13

5) During this step you can test what these ramdisks will really hold. Just try the command:

dd if=/dev/zero of=/swapram/rd10/sw bs=1024 count=500000

It will tell the maximum size it attained before it ran out of space. I would use a number smaller than that maybe 4 to be safe. Then, for example if it said it wrote 129034 I would use 129030, thus:

dd if=/dev/zero of=/swapram/rd10/sw bs=1024 count=129030 dd if=/dev/zero of=/swapram/rd11/sw bs=1024 count=129030 dd if=/dev/zero of=/swapram/rd12/sw bs=1024 count=129030 dd if=/dev/zero of=/swapram/rd13/sw bs=1024 count=129030

6) Now the swap has been initialized. The ramdisks still need to be made into swap: This requires making the swapfiles. In this example I just named them all sw as they are in different directories.

mkswap /swapram/rd10/sw 129030 mkswap /swapram/rd11/sw 129030 mkswap /swapram/rd12/sw 129030 mkswap /swapram/rd13/sw 129030

7) Now Change Permissions

chmod 0600 /swapram/rd10/sw chmod 0600 /swapram/rd11/sw chmod 0600 /swapram/rd12/sw chmod 0600 /swapram/rd13/sw

8) sync

9) Now activate these prepared ramdisk swap files

swapon /swapram/rd10/sw swapon /swapram/rd11/sw swapon /swapram/rd12/sw swapon /swapram/rd13/sw

Now you can issue

swapon -s

and see them. It is now time to (if there is enough memory to swap everything back in)

swapoff /dev/hdxx

Where again xx is repladec by the partition number of the swap partition on the disk drive. You can also assign priorities to the drives (in the swapon command) if you want different ones than they are given by default.

Now it is set so that all swap is swap ram, and you can try your performance.

Other Comments

I did experience a slight problem on one computer that was set up to have quota warnings on all drives. Every day there would be an email, from the system to root, that said a swap drive or two were over XX% full. If this happens, take these partitions out of the quota list.

At first glance, this concept of using RAM as swap sounds a little strange. To get more memory, and then not use it for memory but for swap just doesn't sound right at first. But Linux server administrators sometimes have used fast solid state drives of 4GB (for $10k or more) for this purpose. It seem to me that if you have 1 GB of memory now, even if it requires upgrading the motherboard to one that takes at least 4 GB RAM, and then using 1 GB original RAM and putting in 2GB more to use for swap is going to be less expensive than $10k. A lot less. If the motherboard can already take 2 GB, just add another GB to the original GB (making 2 GB total) and make the new GB swap. When you are done, you have a silicon disk to use as lightning fast swap for way less than a thousand dollars.

There are those that think there might be some bug that would make this swap ram dangerous to use. (There seem to be other bugs that make the kernel dangerous sometimes). My purpose is to make it easy to try this on many (hopefully not too critical, in case of a discovered bug, which then could be fixed) computers and see if it works well over time or not. My experience on 3 computers is that it works well.

Consider this about normal swap setups. Having more memory (and correspondingly more swap space on the hard drive to fulfill "the swap space should be one to two times the size of RAM" 'requirement') might actually make the swap thrashing time expand further. We used to have 64 MB of RAM and a 128 MB swap partition. 192 MB total. The absolute most you could ever swap out and in at once would be something less than 64 MB, the total size of RAM. If hard drives were at 5400 RPM, it took some X amount of time. Now, if we have 1GB RAM and 2 GB swap space, and 7200 RPM drives, to do the same thing, swap out almost all of memory, would take 12X time. This is because, even though the computer processor/memory may be 20 x faster than before, the drives are not even 2x faster.

So, larger memory capacity coupled with little change in hard drive speed has probably this problem easier to notice. Processor speeds and FSB speeds don't matter much when you have to swap something back in from the hard drive. The applications are larger and more complex now, and take more RAM (and more swap when swapped out). So since the hard drive speed is almost the same, but the size of what is swapped out and in is ten times (or more) larger, things get sometimes 10x (or more) slower when swap is heavily in use. Where will we be when we are using 16 GB of memory and 32 GB swap space, and drives are still at 7200 or 10,000 RPM? That will be 16 times longer than what we have now, which would then be about 200 times slower than on the 64MB main memory 128 MB swap example above. I can hardly wait for all the waiting that will involve.

In the O'Reilly book "Understanding the Linux Kernel", by Bovet and Cesati, in Reclaiming Page Frame in chapter 16, it is stated that many programs request program memory and then request more as cache and buffers, and the operating system never releases them until it has to. Add to this that programs many times request much more memory than they will need, just in case, and the reason why Linux memory is full at almost all times is clear.

When swap ram was used on a 500 MHz FC1 computer with only 256 MB of RAM, the results were not that good. First, it was not enough memory, and it didn't speed things up much.

Second, the program 'free' is not made to handle swap RAM. I can see that from the beginning. If I turn off a 500 MB swap partition on the hard drive, then run the command

free -mt

It shows 0 bytes in swap or available as swap. If I then make half of the 256 MB of memory into swap, then it faithfully shows 128 MB in swap, but many times still has more than 128 MB in cache and buffers, so it must not actually be allocating the swap files in RAM until they fill up. Also, free -mt shows the memory total (and this is the interesting part) as the 128 MB of swap plus the 256 MB of physical RAM, which is about 384 MB. The free command actually shows total memory of 384 MB! So talk about your virtual memory. There are only 256 MB of RAM on that system, and the physical hard drive swap partition is off, but the total memory with swap in RAM is now 384 MB! Almost sounds like an accounting trick.

So it looks like nobody expected swap to be placed in RAM. But even though this accounting error exists, I have had no problem with the swap in RAM, unless the amount of RAM is too small in the first place. The recommended RAM for these later versions of Red Hat is more than 128 MB, so it was good to test this on the 256 MB RAM system, but it provided no performance gain. With at least 512 MB of RAM it provides definite gains. No more long waits for the next workspace to appear.

This idea of using swap RAM is just the result of trying to deal with the way Linux handles the virtual memory subsystem. The only reason there is virtual memory in the first place is that there wasn't enough RAM for the programs, but there was a lot of cheaper disk space. This is why this complex superstructure called Virtual Memory exists. If we just had enough memory in the first place, there wouldn't be swap. Everything could be in memory. You would still have to use the hard drive to load programs and store data, so there would still be caches and buffers to lessen the impact of having to actually write to or read from the (about 50,000 times slower than RAM according to Riel) hard disk. But caches and buffers would not be allowed to take up all free RAM like they are now. They would be controlled, if swap was not available. That would save a lot of code and complexity, making the kernel more reliable, with less places for bugs to exist.

But we do have swap tightly integrated into the kernel. So, it seems that there should be some swap, even if it is swap RAM. (All I can say is my computers run more smoothly with ram swap than with no swap at all). And it could be that the kernel code will be satisfied (run well) with perhaps only 200 MB swap in a 1 GB physical memory system. 800 MB main memory, and 200 MB swap in RAM. That can be a part of this test.

So, please use this to make and use swap in RAM, and report on the results to discussion groups. There is nothing like many people testing this to see how well it works. No more speculation and a pirori knowledge of what might happen, but observation of what does happen.

If you like how this works for you, you can make a script to set it up so you can either turn it on when you want, and not if you don't want. If you want it to persist after a reboot, you will have to put the script in the initialization scripts area. I did this, and it is nice to just forget about it after that. No swap thrashing is nice, and sometimes I don't even remember it is set that way. Perhaps most people reading this have no need of help with scripting or init.

In the script, you have to put in all the steps except the making of the mountpoint directories. Again the steps are:

use mke2fs to put the filesystems on the /ram* drives on your system

mount the ram* 's to the already existing mount points

fill them with zeros to initialize them.

use mkswap to make them into swap.

change their permissions to 0600

sync the filesystems

turn them on as swap with swapon.

turn off the swap partition on the hard drive (optional)

Sample Script

This script is just a sample. For your particular situation you may be using more or less ramdisks, of different size. The procedure above should be done manually at least once so that the count number is known accurately. This was written when the mountpoints were in the root directory at /rd1 through /rd9, different from the example procedure above. /dev/ram1 was not used as it was already linked to something else, so I used /dev/ram10 instead. All the steps are shown in the first 8 lines (for the first ramdisk). The rest is a repeat to get all the others ready and working. The priorities in swapon are set to be higher than the hard drive swap partition priority. If you set your ramdisk_size large enough you would only need one ramdisk, and thus would only need the first 8 lines of this example.

#!/bin/bash mke2fs /dev/ram10 mount -t ext2 /dev/ram10 /rd1 dd if=/dev/zero of=/rd1/sw bs=1024 count=56000 mkswap /rd1/sw 56000 chmod 0600 /rd1/sw sync swapon -p9 /rd1/sw #   mke2fs /dev/ram2 mke2fs /dev/ram3 mke2fs /dev/ram4 mke2fs /dev/ram5 mke2fs /dev/ram6 mke2fs /dev/ram7 mke2fs /dev/ram8 mke2fs /dev/ram9 #   mount -t ext2 /dev/ram2 /rd2 mount -t ext2 /dev/ram3 /rd3 mount -t ext2 /dev/ram4 /rd4 mount -t ext2 /dev/ram5 /rd5 mount -t ext2 /dev/ram6 /rd6 mount -t ext2 /dev/ram7 /rd7 mount -t ext2 /dev/ram8 /rd8 mount -t ext2 /dev/ram9 /rd9 #   dd if=/dev/zero of=/rd2/sw bs=1024 count=56000 dd if=/dev/zero of=/rd3/sw bs=1024 count=56000 dd if=/dev/zero of=/rd4/sw bs=1024 count=56000 dd if=/dev/zero of=/rd5/sw bs=1024 count=56000 dd if=/dev/zero of=/rd6/sw bs=1024 count=56000 dd if=/dev/zero of=/rd7/sw bs=1024 count=56000 dd if=/dev/zero of=/rd8/sw bs=1024 count=56000 dd if=/dev/zero of=/rd9/sw bs=1024 count=56000 #   mkswap /rd2/sw 56000 mkswap /rd3/sw 56000 mkswap /rd4/sw 56000 mkswap /rd5/sw 56000 mkswap /rd6/sw 56000 mkswap /rd7/sw 56000 mkswap /rd8/sw 56000 mkswap /rd9/sw 56000 #   chmod 0600 /rd2/sw chmod 0600 /rd3/sw chmod 0600 /rd4/sw chmod 0600 /rd5/sw chmod 0600 /rd6/sw chmod 0600 /rd7/sw chmod 0600 /rd8/sw chmod 0600 /rd9/sw sync #   swapon -p8 /rd2/sw swapon -p7 /rd3/sw swapon -p6 /rd4/sw swapon -p5 /rd5/sw swapon -p4 /rd6/sw swapon -p3 /rd7/sw swapon -p2 /rd8/sw swapon -p1 /rd9/sw

‹ Linux Kernel Module mini-kernel hangs with mkdump-3.0 and RHEL 3 and mini kernel - 2.6.12.2 ›

* Add new comment

no need for swap biscuitman on August 18, 2004 - 4:06am

If your memory is big enough you dont need swap. Thats why its better to buy an athlon64 and more than 4G of memory. Swap was invented to make up for expensive ram. The method you are suggesting only wastes ram space for the overhead. Swap is a trade off between expensive ram and cheap hd space. What if you start running out of swap space in your setup? Thats why some databases using an memory bound design instead of being diskbound with a very big buffer cache. The data that was always in memory in the buffer cache were not able exploit the optimizations possible in memory. Same for the data in swap its not directly usable by your programs.

* reply

Is swap necessary? Anonymous on August 18, 2004 - 8:53am

It's not quite that simple.

See http://kerneltrap.org/node/view/3202 for more.

* reply

Also Anonymous on August 18, 2004 - 9:00am

Swap is also good to relieve pressure on a zone. A small RAM based swap device effectively provides a page migration facility for anonymous pages where they might otherwise clog up a zone's memory.

* reply

Migration kasperd on August 28, 2004 - 8:27am

A small RAM based swap device effectively provides a page migration facility for anonymous pages where they might otherwise clog up a zone's memory.

That might be true. But if that is really the case, it does not indicate that using RAM as swap is a good idea. OTOH what it indicates is a minor design flaw in the current memory management design. If there is really a need to move data from one part of RAM to somewhere else in RAM, the memory management should be able to do that without the use of swap.

* reply

Moving data around in RAM kmerley on December 5, 2004 - 5:04pm

A minor flaw with irritating consequences. Enough that people are throwing caution to the wind and going swapless. kswapd gets a little tangled up sometimes with no swap.

However, they seem to have done something like you said. It looks like some of the parameters of the swapcache were changed so that more stays in it (everyting that is swapped out or in goes through the swap cache). So now, there is a much better chance that when what has been swapped out is needed, it can be obtained from the swap cache which is in RAM, and that happens as fast as swap in RAM. It is swap in RAM. Moving data around in RAM is a feature of Linux.

* reply

Confused Anonymous on August 18, 2004 - 11:57am

This has me confused. That discussion doesn't seem to help much either, as they don't agree on whether swap is good or not!

AFAIK, swap is not addressable directly, so if you allocate part of your memory as swap, anything in it has to be swapped into "real" memory before it can be used. So you've reduced the maximum size of the working set, and increased latency for accessing the "swap" portion of memory.

You've reduced swap access time (compared to a HDD based swap), but as swap only gets used when memory starts to run out, you wouldn't be swapping much anyway with the increased memory. Wouldn't tuning swappiness be a better approach?

Given that memory is expensive and limited in maximum size (by number of motherboard slots and the 4GB limit for 32-bit), how can that be a good idea? If it does improve performance, wouldn't that indicate a flaw in the Linux memory system, rather than that memory-based swap is a good idea?

* reply

Actually, the 'problem' is th Anonymous on August 18, 2004 - 2:48pm

Actually, the 'problem' is that Linux is swapping more often, it's swapping when it has enough memory available, it's using it as directory- & file-cache.

Because it think's it's the best policy and it probably is for a lot of situations, but the policy might need a chance to be even better (especially for desktop-use).

You could say Linux has a swap-early-algorithm.

see ya, Lennie

* reply

If you replace all your swap- Anonymous on August 18, 2004 - 3:16pm

If you replace all your swap-space by extra memory you could simply turn all swap off.

I still fail to see how replacing 'swap to disk' by 'swap to memory' will improve performance; no available swap means no possibly detrimental 'swap-early-algorithm'.

* reply

purpose of the article Anonymous on August 18, 2004 - 11:42pm

I think, if you actually read the whole article, that your confusion as to the purpose of using primary RAM as a swap would be laid to rest. What I got out this article was this: Linux does not function well (the screen flickers) if you try to "turn it down," therefore, you can use RAM, instead of virtual memory (your HD) to "jimmy-rig" linux, or fool it into running faster.

Of course, I could be wrong, but I, like the original author, am just trying to be helpful.

* reply

Linux functions well without swap. Anonymous on August 23, 2004 - 4:56am

No, on my notebook I turned swap down a year ago, and have no single problem with that. (2.4, Suse9.0, 384MB; sometimes start vmware~180MB)

* reply

At least for your usage. Anonymous on December 6, 2004 - 5:53pm

Getting rid of swap with only 384 MB of memory might result in some out of memory problems. (Trying to use swap ram wouldn't be a good idea either with just 384 MB RAM.)

Just make sure you continue to use only programs that don't take major amounts of memory or sometime you might lose a process, and maybe not the one that will do you the least harm. Well I guess if you are never working on important data an oom wouldn't hurt. Go for it.

* reply

Nope. I have only 384 MB of Anonymous (not verified) on April 30, 2005 - 9:13am

Nope. I have only 384 MB of RAM on my laptop and I have swapped turned off to get better battery life and better performance. I rarely get above, say, 180 MB of application allocated RAM (even when running KDE, music player, Konqueror, several Konsole sessions and sometimes Windows programs with CXOffice), so I have a lot of room before I have to start worrying about OOM conditions.

* reply

If you replace all your swap- Anonymous on August 19, 2004 - 3:03am

I still fail to see how replacing 'swap to disk' by 'swap to memory' will improve performance; no available swap means no possibly detrimental 'swap-early-algorithm'.

Due to Linux' usage of swap space, a swapping setup merely dictates implied priorities of memory. If all the memory is equal (e.g. no swap), it's all being used equally. Splitting your memory into primary half and a secondary half (memory-swap) enables Linux to acknowledge that there actually is space for more important and less important data, and to let its VM implementation leverage on that (and that's what it's optimized for, bearing disk-swap in mind).

* reply

Thanks Anonymous on August 19, 2004 - 6:35am

Thanks, that's the first time I read an explanation that makes perfect sense, and even a non-techie would understand (and I consider myself a techie).

* reply

I'm still confused Kannan Goundan (not verified) on June 14, 2005 - 8:47pm

How can it help to leverage incorrect information? Can someone provide a sequence of events where a 1.5 GB, no-swap setup will perform worse than a setup where part of RAM is dedicated to swap?

* reply

Incorrect Information kmerley on June 19, 2005 - 3:48pm

In answer to: "How can it help to leverage incorrect information? Can someone provide a sequence of events where a 1.5 GB, no-swap setup will perform worse than a setup where part of RAM is dedicated to swap?"

What is this incorrect information? I am guessing the incorrect information you are referring to is that swapless is better than using swap. That indeed may be incorrect information.

kswapd and bdflush expect swap. When you shut swap off, kswapd and bdflush are still active, and will be. If you look at the emails shown in the original "Is Swap Necessary" article you will see some respected kernel developers commenting that they don't consider it a good idea to disable swap. The kernel expects swap. However, like Windows 98 and ME being the consumer versions of Windows, and they are a lot less stable than NT and win2k, it probably won't hurt to use Linux without swap for non-server applications (consumer uses). It could probably be used where the load is a lot less and it doesn't slow down any serving functions if kswapd and bdflush are tearing out their figurative hair trying to fulfill their functions in the presence of no swap. It is probably not a good idea to shut swap off on an important server.

I have an idea for a new Linux distro, called Consumer Linux, and its specialty is that it comes with swap shut off as the default.

Like I said before, if you want to use no swap, go ahead. If you already are, keep going.

If you just added 256 MB more memory and made it into a ramdisk swap area there would be the advantages that kwsapd and bdflush could work like they were designed to work, plus your workspace could be a slight bit larger before there would be any out of memory problems.

It would be great if you could activate "emergency swap", which would not be used except in an emergency. It is just that the kernel's idea of an emergency happens quite often. This emergency swap area would only be used if the OOM were about to be called, and a warning should be given, or an email sent to the administrator for a server. This warning is already in use for disk space, so it should be easy for RAM+Swap space too low.

So, a process is about to be killed, but we (in the future) have an emergency only swap partition. Instead of choosing a process to kill, it swaps it out, and sends a message to the screen or an email to a systems administrator, or both. Maybe it sends a message through a beeper or cell phone. Now it should be a lot easier to recover from. The kernel might try to empty the emergency swap area as soon as possible, but it keeps sending out messages say every 15 mintues until it succeeds in purging the emergency swap area or the situation is otherwise remedied.

* reply

Ok, I got 1 GB of swap but usually < 500 kB of it is in use Anonymous on August 20, 2004 - 4:41am

Before blaming swap, can you verify (using top, /proc/meminfo or something) that it's actually swap use that is the problem? I've never seen Linux swap over about 500 kB in normal use without rebooting over the weeks, (although I have seen that Linux blows the filecache away when you do large directory copies). Filecache, however is not swap...

When you switch to a long-laid-dormat application and it appears to page it in from the disk, it's probably not coming from swap, but actually Linux has thrown away the unchanged read-only pages of the executable and its shared libraries, and it's reading them anew.

The guys who suggest buying 1536 MB of memory and using 1024 of that as swap are obviously insane. Pay no heed. In my experience, that would be approximately 1023 MB physical memory *totally* wasted.

* reply

This does not sound like 2.4, might be 2.6 kmerley on August 20, 2004 - 9:07am

Are you sure it is kB? I have never seen this situation of only 500 kB in swap. In 2.6, which I am starting to test now, it has 0 kB in swap for a long time, and that is great. But in your situation, it sounds like your hard drive swap is totally useless. Unless it is a 500 kB hard drive swap, and that is how you got it to not have more than 500 kB in swap.

You know, for your situation, if this is actually true, you could have a luxurious 1 MB swapram, and get rid of any apparent latency from swapping the 500 kB back in, and use the hard drive swap as another storage partition.

* reply

Um, I am using 2.6 kernel Anonymous on August 24, 2004 - 5:41am

Yeah, I'm positive it's in kB. Right now: 348K says top.

If the bad swappiness of 2.4 is a problem then I shall shut up. I see no difficulties at all in 2.6. None of my systems swap more than that 500 kB (and they all run 2.6). And I don't believe in the 1 MB of memory swap still -- the fact the swapped amount lingers on and on is probably a proof that it's not used and doesn't need to be swapped in, either. So why waste the memory to hold even that 1 MB of data, which I don't actually believe is ever going to be swapped in. And how long can it take to read 1 MB from disk, like, 10 ms?

I keep about 200-300 MB of swap because when I do run a memory hog that threatens to trash the system, those 300 MB permit me time to notice and break the app before all filecache is blown away and the system truely grinds to a total halt. I write perl CGIs and stuff like that for work, and in an occasion an infinite loop or recursion creeps in the code, and when you notice it takes longer than usual to get a response, you must hurry to killall -TERM foo.cgi. There's some interesting patches right now coming in that finally shall fix this (maximum resident set size) problem, and I'll probably drop swap down to 50 MB or so...

* reply

It is 2.4 mostly kmerley on September 4, 2004 - 11:40am

It is a 2.4 problem mostly. But in using a knoppix-debian 3.4 install with 2.4, it only is using 1.5 MB after 14 days, and I have had many many programs used in that time. Where I see this problem, right now, today, is on my 400 MHz laptop with its 128 MB memory, and it has knoppix 3.3 hd install. Right now it has 111 MB (swap about half full) in swap, and it is at least 20 seconds to go from one app to another, like to a console from a Mozilla page. So I think the swapram is a workaround that will work best for older equipment. Or for a heavy usage situation in 2.6 where there is a lot of swapping.

* reply

Depends on usage Anonymous on August 24, 2004 - 12:55am

It simply depends on usage. 512 MB of RAM would, in my system, be fully in usage. I have 256 MB RAM and 256 MB swap and my swap is heavily used i promise you that. This is on a desktop. I basically run a browser (Epiphany) with a fair lot of windows open (which takes 20-30% memory usage), GNOME + X (other 15%), several P2P apps written in Python (BitTorrent 3%, Nicotine 25%) a multimedia player, several services on the background and sometimes even Pan (which use 50% of my memory in some bad moments!). But take Pan out of account already because when i start that up either Pan or Epiphany gets killed.

Do you see that i cannot use other applications anymore and that the system is already fairly slow? I can't start up the GIMP now. I better not use Nautilus now. Heck, even Gnome-terminal is slow now. Which is, IMO, pretty sad but also due to my usage. Nicotine uses too much. Epiphany should have less windows open. A lil bit more RAM (one bank free) and i should be fine. Or buying a better mainboard, CPU, and faster RAM would also result in more snappiness. But i'm lazy and don't want to spend money.

* reply

Latency problem Anonymous on August 18, 2004 - 3:05pm

"You've reduced swap access time (compared to a HDD based swap), but as swap only gets used when memory starts to run out, you wouldn't be swapping much anyway with the increased memory"

I believe the VM in 2.4 and 2.6 is always using swap (for inactive pages from what I've read (this is probably not the correct term and I'm sure others will comment correctly on this)). Run a monitor to keep an eye on your swap space.

So if swap is always being used and memory is not too expense then setting a side memory as a swap space solves the latency issue with using hard drives as swap spaces (especially when Mozilla or OOo is being swapped back in after not being used for hours).

* reply

Dmcrypt Anonymous on August 24, 2004 - 12:45am

One reason to not use (non-encrypted) swap is because of Dmcrypt usage. When you use an encrypted partition you don't want your swap-space to contain the password to access that encrypted partition, or other sensible, related information. You either don't use swap, or use an encrypted swap. The latter is ofcourse also possible on Linux.

Some people don't even trust their RAM on this. For the paranoid ;)

* reply

Yes, if there is enough RAM swap should be unnecessary kmerley on August 18, 2004 - 9:06am

AS you say, swap was invented because there was not enough RAM. If there is enough RAM, swap is not necessary. However, the kernel has been written around swap, so when it is not there, it seems to work a little funny.

What does Athlon have to do with it?

If I had 512 MB of RAM and 1 GB swap on disk in the first place, then replaced the 1 GB swap on disk with 1 GB swap in RAM (added 1 GB of RAM), how would I be running out of swap space any faster than before?

* reply

What does Athlon have to do w Anonymous on August 18, 2004 - 10:04am

What does Athlon have to do with it?

Athlon64 allows more than 4Gb RAM (as do other 64bits archs)

* reply

So Jeff Flowers (not verified) on June 20, 2005 - 2:36pm

this reveals a poor programming method, since it should not be assumed that one would always be using swap? Are there an easy fixes for this behaviour or would it require some real effort to make the kernel work well in swapless environments?

* reply

It probably just happened that way kmerley on June 21, 2005 - 11:44pm

Probably swap just was always used in the early days of very little RAM, and now it is like removing IE from Windows.

I don't know how much effort it would be to optimize the kernel for using no swap. Maybe just tweaks of the kernel threads like kswapd. Maybe it would be thought to be a small effort and then it actually opens up a whole can of worms.

I think this was what occasioned the "Is Swap Necessary?" thread on this site:

http://kerneltrap.org/node/3202

There was partially a desire that it would be said "Yes, running swapless is completely OK." But what seemed to be said by kernel contributors was that it may not be completely OK to run swapless. I know that running swapless occasions a lot of time being used by kswapd because it is charged with freeing memory but it has no swap to help free memory with. So sometimes it gets a little tangled up, but it doesn't seem to crash. Go swapless and watch what happens with top during other operations, like bringing up a new application or picture in Gimp.

Anyway, would it be a large effort? Probably.

* reply

there is one case where it makes sense peterhoeg on August 18, 2004 - 11:26am

I had an old machine that could only cache the first 128MB of RAM (motherboard: Aopen AX59Pro). Adding in an additional 128MB gave slowdowns. In that case (and that case only) did it make sense to use the remaining 128MB as swap space.

* reply

Been there... Mr_Z on August 18, 2004 - 2:31pm

Been there... Only it was w/ an old 386 MB that could cache the first 16MB, but nothing more. When I tried going up to 20MB it got WAY slower. If I could've designated the slow 4MB as "disk buffers only" or as a RAM disk for the paging file, I'm sure it would've been faster.

In general, if you have different physical classes of memory with different access latencies, it can make sense to designate the slowest portions as "swap." If you have a mixture of slow RAM and spinning rust to use as swap, you could use the swap priority feature to bias things towards the slow RAM.

The thing is that most of the easily obtained high-density memory is also fairly fast. Fast enough that it doesn't make sense to use it as a swap partition.

Kim has one good point that she posted in the forum: The kernel seems to assume swap is present, and so its algorithms seem to behave oddly when there is NO swap. While I consider that a bug, a reasonable workaround would be to have some small amount of "swap" that the VM keeps aside. It's somewhat like a victim cache in a microprocessor's cache.

* reply

Good Comment kmerley on September 1, 2004 - 11:08pm

Mr-Z, I had never done this before and didn't realize how good your comments here were.

* reply

Example Anonymous on August 18, 2004 - 11:34am

Suppose you have 512MB Ram and two (GUI) applications running. Now you don't use application B for a while, but application A opens a large number of files. Any OS will now use RAM as a file cache and move application B to the swap space. (On linux this can be controlled with the swappiness parameter, but ultimately the same will happen). This speeds up application A, but if you want to switch back to application B the OS will have to load it from disk.

Now if swap consists of RAM, loading application B from swap will be much faster.

Of course this only brings an advantage in very special situations. Generally using RAM as RAM and possibly fine-tuning swappiness is the better way to go.

* reply

No. If you have 1.5GB ram and no SWAP, no Anonymous on August 18, 2004 - 11:51am

application will be swaped and no application will need to travel form RAM to RAM. Make memory to SWAP only makes overhead, and it's no useful.

* reply

Not necessarily Anonymous on August 18, 2004 - 12:28pm

The OS might decide that it is better (in the short run, i.e. until app B is needed again) to use all RAM for the file cache.

* reply

No it wont. turpie on August 18, 2004 - 9:36pm

No it wont. If app B is in RAM and there is no swap, then app B cannot be swapped out.

If you use half your RAM as swap then app B might be swapped out to the swap-RAM. When you need to use app B again it will need to be copied from swap-RAM to regular RAM. Copying from RAM to RAM will be quicker than copying from HardDisk to RAM, but it will still be slower than not having to copy at all.

It is possible that there is a problem with the linux VM that makes using a RAM drive as swap beneficial, in which case you should find some way of benchmarking and accurately measuring the difference so that the developers can work on solving the problem.

* reply

I completely support finding accurate benchmarks and testing. kmerley on August 19, 2004 - 12:44am

I completely support finding "some way of benchmarking and accurately measuring the difference so that the developers can work on solving the problem."

For me, though, 30 seconds using disk swap verses 0.5 seconds for swapram with the same number of applications up, same amount of swap used, is a good indication.

I would be glad to not have to wait 30 seconds sometimes to bring up the swapped out application. Well, actually I am glad not to have to on my machines with enough RAM to use swapram. On my 128 MB laptop I still have to wait.

* reply

compare swapram with noswap-at-all Anonymous on August 19, 2004 - 1:37am

Ok, with ram-swap you will get 0.5 seconds instead of 30 seconds with harddisk-swap...

but how fast will it be with no swap at all, when using all the memory (1.5GB)?

* reply

About the Same, but flickering display in my experience Anonymous on August 19, 2004 - 3:55am

About the same, but try it. It will probably be different with different hardware. I have only had 1GB max so far.

* reply

I completely support finding accurate benchmarks and testing. Anonymous on August 26, 2004 - 11:08pm

I would be glad to not have to wait 30 seconds sometimes to bring up the swapped out application.

Although I fully expect to not receive any response (given your past history), I'm still going to ask my question.

Would you please post an exact listing of all the applications you have running (and how much memory [RSS field in top] they each consume) when you experience this 30 second wait for an app. to "return" from swap, and as well, tell us which app it is that you wait 30 seconds for it to return. And also, please give a small description of what your typical usage pattern might be like.

The reason I ask is that I've got a system here that's my main desktop, which isn't too far different from what description you've given for yours. It [mine] has only 512MB RAM in it (just like your origional setup), and it's HD isn't a super speed demon by todays standards (about 22MB/sec from hdparm -t -T timing), and I keep a whole slew of apps open at any given time, sometimes even running a monster memory hog. FWIW, my Mozilla instance right now by itself is eating 124M of my 512M of ram. And I'm also running a 2.4 kernel, and I've done nothing to stop it's swappiness (I rather prefer it, and when I do upgrade to 2.6 finally, I'll be one of those in the "make it more swappy" camp. And I've never, ever, except when I've done something intentional, like run an eatmem to consume all available ram, experienced a situation where Linux has swapped so much on its own, of its own accord, that I've ever had to wait 30 seconds for an application to return from swap when I've not touched that application for days or weeks. Never. Yes, I've noticed the swapiness, and I have had to wait a few seconds sometimes for something to return. But I've never sat for 30 seconds (unless I did something like the eatmem pressure test) for anything to return from being swapped out because the kernel VM decided to free up some RAM for better usage.

The only time I've encountered anything at all like what you describe is on the little Linux box I have at work under my desk. But it's also only got 192M of RAM, and a HD so old that it only achieves about 4M/sec or less of hdparm -t -T speed. So I know exactly why it sometimes takes many seconds (bordering on 30) for something to come back when I've not touched it for a few days. Couple that with the fact that I'm running a whole bunch of stuff all at once (more convienent to let it swap back in than restart it) including Mozilla, Openoffice, and a whole host of other little bits and nits, that I'm actually way short on RAM at only 192M of it. But even there, the 30 second waits are maybe once or twice a week, not so often as to be horribly bothersome.

* reply

It will still be evicted from RAM! Anonymous on August 24, 2004 - 6:07am

Shared libraries, code pages, mmaped files (eg many temp/cache files) will still be evicted from ram and have to come back in of the drive. Not technically swapping, but the symptoms are the same

* reply

Don't need Swap? Might be good though. kmerley on August 30, 2004 - 3:05am

Your comment "If your memory is big enough you dont need swap." may be true on other systems, but at least a couple authoritative Linux kernel contributors state good reasons you should have some. Look at the former discussion

http://kerneltrap.org/node/view/3202

In one example, in an email, Rik van Riel states that if there is no swap, then things will get evicted from caches, and that will require disk access (the slow process that all the caches try to make not necessary) to get it back when needed. This may not be noticed at application switching times, but at other times applications need what got evicted, and it might not be known that this is occurring. Something would slow down, and you wouldn't know why, but you would assume it wasn't anything to do with swap because you shut swap off. But then, maybe it did have something to do with swap.

* reply

Is there no need for swap? kmerley on September 1, 2004 - 10:43pm

" If your memory is big enough you dont need swap."

This could be true. There are many readers posting good reasons for having at least some swap, and van Riel and Piggins state good reasons in the last discussion on swap "Is Swap Necessary" on this site. However, if your memory amount is very large, you are probably right. I don't think that many Linux desktop users have that much memory.

"The method you are suggesting only wastes ram space for the overhead. "

Not in the scenario of replacing hd swap with swapram. Main RAM overhead is still the same. There is the increased overhead of swap cache in a swapping system verses swapless. (On my system running with hd swap, right now almost 10% of memory is shown as SwapCached in /proc/meminfo, that is, 24 MB out of 249MB RAM, and it is 3% of total memory. So if I replace the 512 MB hd swap with 512 MB of memory, there will still be that 3% of total memory waste. If I put in only another 256 MB stick, the waste in swapcache will be about 5%.)

I put this little article together as a result of two events. The first was a computer (that I no longer have, and which now has a different hd in it, a 60G instead of a 30G, so I can't get the hdparm for the original conditions) that I noticed had a lot of waiting time for an application to become available again. I found out it was from swapping back in. I noticed that free said it only had 5 MB free, but it had many hundreds of MB free (1GB total RAM) considering caches and buffers. So I did think the VM was making bad choices for my usage. I couldn't quickly find out how to tune that, but I could find out how to make a ramdisk work as swap. That solved that problem. That was Sept 2003.

[There it is again, only it is more ironic this time. There is a little ad right across from this text entry window which says:

Speed Up Windows Eliminate disk I/O bottlenecks with Cenatek RAMDisk and Rocket Drive www.cenatek.com

And it is to speed up Windows!

Targeted advertising for Windows on a Linux site.]

Then, about a month ago I found the discussion here on kerneltrap about "Is swap necessary?" (from the end of May 2004). The second comment to that article was a suggestion to perhaps use swap in a ramdisk. Since I had this procedure that worked on multiple platforms, and since I didn't see anywhere in that discussion (I didn't go through it with a fine tooth comb) someone talking about trying ramdisk swap, I thought I would write up the procedure that worked for me so that it would be easier for others to try it also, if they had an inclination. Since it really made my desktop experience much more enjoyable, I knew it could make some other desktop users' experiences more enjoyable also.

The first machine I tried it on had 1GB, so even splitting it into 512/512 was not going to be a problem for my memory needs, which seem to be more in the realm of 256/256.

It is true that you better have enough memory for your needs, and if you split your memory to have swapram and shut off the hd swap, and this leaves you without enough memory, there will be problems from not having enough total memory. The same applies if you just shut swap off. If you need the extra memory provided by the swap, just turning it off will perhaps cause some real data loss if your process with your work data in it gets summarily killed by the OOM. That happened to me recently when I was running swapless with 256 MB memory on FC1. No warning, no graceful degradation, just process killed by OOM.

If you are not sure about your memory needs, but you are OK with your current RAM plus hd swap, then, whether you go swapless or use swapram, you should get more RAM, equivalent to your current hd swap space, and put it in. Then you are pretty safe. After that point the differences between no swap and swap ram are more arguable, that is, not as data threatening.

However, many kernel contributors argue in favor of at least a small swap space. Perhaps that could be fulfilled with a small swap in ramdisk. If it is swapram, it will be a lot faster swapping whenever it does occur.

Kim

* reply

Swapram data is essentially directly usable to programs kmerley on April 12, 2005 - 3:38pm

"Same for the data in swap its not directly usable by your programs."

At the speed that swapram runs, the data is available to the program in almost the same time it would be available if it were residing in a RAM cache. It is available thousands of times faster than it is from swapdisk.

* reply

Oh dear Anonymous on August 18, 2004 - 8:38am

This is by far the worst article ever been on kerneltrap.

Say you have a Linux system, and you are noticing latency. Then you find that the slowness is from the time taken to swap programs back into main memory. Say you have 512 MB of RAM and a 1 GB swap partition on hard disk.

So when you don't like waiting for pages to come back from swap to RAM, why do you have so big swap space?

What is "the swap space should be one to two times the size of RAM" 'requirement'? There is no such thing. Period.

You can afford a gig more of RAM? Great! Do it. Plug it in and you will see performance improvement immediately. But after you have a gig more RAM, you will still see another performance benefit when you add another 256MB of disk as a swap space.

Robert.

* reply

So, if I reduce the amount of swap, there will be a benefit? kmerley on August 18, 2004 - 9:16am

So, if I reduce the amount of swap on disk I won't have to wait as long for things to page back in? Then I better make sure I have at least some amount of disk swap for more preformance benefit? Interesting.

A gig more RAM is a lot more affordable than a solid state storage solution of $10k or more. With the solid state solution, though, it satisfies the mind that RAM is being used for RAM and some type of drive is being used for swap, like it is supposed (background cosmic law or something) to be. And apparently this applies even if the solid state solution is expensive and actually is RAM itself.

I like the IRIX described, that it automatically reduces swap space if you add more RAM. Great idea.

* reply

You're missing the point. Mr_Z on August 18, 2004 - 2:43pm

You're either missing the point, or persistently trolling. Not sure.

Here's the scenarios, ordered from "slowest" to "fastest" (measured in terms of performance potential on a reasonably large working set):

1. 0.5GB RAM + 1.0GB swap-on-disk 2. 0.5GB RAM + 1.0GB swap-in-RAM 3. 1.5GB RAM + no swap 4. 1.5GB RAM + 256MB swap-on-disk

Basically, if you have money to spend on an extra 1GB RAM for your system, you're best off making it available as RAM, not as a swap partition. Adding a swap partition on disk on top of that extra RAM would make you "faster" still.

I put "faster" and "slower" in quotes, simply because more RAM doesn't always equal more speed, if it's more RAM than you need. It can actually slow you down if it bloats up the data structures the VM uses for managing it, though that doesn't seem to be a gigantic factor. (It can be on 32-bit x86 if you cross the 1GB mark. The 4GB mark brings another delta slowdown.)

Part of the reason having at least *some* swap is useful is that it allows the VM to push dirty pages to disk. If you don't have any swap, the VM can only discard clean pages--usually text pages from executables and disk buffer pages for files read from disk. These pages aren't always in nice contiguous zones on disk, and they don't always represent the best pages to push out of memory. You might end up thrashing on these pages, bringing with it nice seeks all over your disk.

* reply

Thank You Anonymous on August 18, 2004 - 3:31pm

for bringing much needed clarity to this discussion.

* reply

Are these Scenarios tested? Anonymous on August 18, 2004 - 7:26pm

"Here's the scenarios, ordered from "slowest" to "fastest" (measured in terms of performance potential on a reasonably large working set):

1. 0.5GB RAM + 1.0GB swap-on-disk 2. 0.5GB RAM + 1.0GB swap-in-RAM 3. 1.5GB RAM + no swap 4. 1.5GB RAM + 256MB swap-on-disk "

Is this the result of testing? The clause "measured in performance potential" makes me wonder if this is just anticipated performance potential. For me, 1GB with no swap is about the same as 1GB split as 512 MB main and 512 MB swap-in-RAM, or 800 MB main RAM and 200 MB swap-in-RAM. And both these are much faster than 512 MB main and 1GB disk swap or 1GB main and 1GB disk swap.

That mostly corresponds to your list, but if I turned the disk swap back on, with swap=in=ram still on, about the time I get more than 100 MB in the disk swap, it is very slow getting that back out to main RAM. The swap back in time remained the same. It is the same hard drive on the same disk drive interface.

* reply

/tmp not swapon Anonymous (not verified) on January 13, 2005 - 3:46pm

After reading this article I had to laugh a bit. If there's any place that you need to replace HDD with ram then it's /tmp. but then Linux will manage the cache far better than I could so why bother.

Instead of wasting time of weird I need swap-in-ram scenarios fix the kernel so that using the ram as ram is faster.

* reply

exactly Anonymous on August 19, 2004 - 3:01am

This was exactly the poit of may previous 'oh dear' post (now legitimately marked as flame-bait, sorry about that).

We have to think in economy terms here.

Adding 1GB of RAM has cost $X. Adding 256MB of disk-based swap space has cost $Y, where Y<1.0.

Performance boost of adding 256MB of swap is W. I believe that W>1.0 also.

In case of adding only RAM, we have marginal performance/cost ratio of Z/X

In case of adding RAM and swap, we have marginal performance/cost ratio of (Z*W)/X which is better than the previous one.

Another point here is, that adding 1GB of physical RAM and making some part of it a RAM-based swap has lower performance boost than adding all as RAM because of overhead.

And, about the latency problem, you can limit maximum latency time by limiting the total size of SWAP. Only have as much disk-based swap, as you are willing to wait for the whole amount of it being read back to main memory.

It's simple math.

Robert

* reply

Where is the supporting experimental data? kmerley on August 19, 2004 - 4:00am

Better than simple math (based on assumptions in some places) is having implemented swapram and tested it to see if it works as assumed.