Article submitted by Kim Merley
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
This is dumb
Say you convert half of your ram into swap, it will want to swap in half the time you that if you'd had th full ram, but it will swap quickly. But if you had not have the swap as ram but rather leave it as ram, then no swap would occur, so you are in fact less efficient.
All in all, this is really dumb. I mean, come on guys (& gals), isn't it obvious? I have nothing personnal against the author, and to be fait to him/her, I have not read the name, but if I'd be him/her, I'd seriously think about permanently change my nickname.
Swap space has been created to emulate ram on disk, so emulating the emulated ram in ram seem pretty pointless to me. I have lost enough time here. I have better things to do.
He's on crack
Are we April 1st?!? What's next? Create a virtual ramdisk into a swap partition? This is either silly or a joke.
exactly what I wanted to ask the author
If i have 512 MB RAM, should I now divide it to 256 RAM and 256 swap? If not, please, answer another question. Someone already has 1.5 GB RAM. After he read your article, should he change his setup to 512 RAM and 1024 swap? I suppose, the author's answer is "yes". And I thought computer science is a logical disciple...
Another person who knows the answers without knowing
Another "everybody knows this because it is obvious" type post. The new version of the Flat Earth Society. I know it sounds crazy, but it works well for me. You haven't tried it, nor will you, secure in your 'knowledge".
Yes, but...
you didn't bother to show any concrete numbers (poor testing methodology), and you failed to provide any performance comparisons with just leaving 1.5GB as RAM without swap. Why did you not provide this information?
Ok, maybe you're right and we're the flat earth types. But if you're going to make a totally off the wall claim such as this (i.e. the earth is round), then you must be prepared to overcome our skepticism with a mountain of hard, incontovertable evidence. As it is, you have plainly failed to do that. You certainly won't get a skeptical crowd to provide it for you.
Maybe try again when you have significantly better numbers...
Yes, but... (of course)
She didn't provide it because she didn't do it (test with 1.5G ram without swap). I'll overlook the obvious insult statement now......
She simply saw the following: 1) swapping to disk is making my machine slower than it should be. 2) what can I do to speed it up? 3) make swap a solid state device. 4) ouch $10,000 is too much when I can buy 1G ram for $100. 5) Wow, having 1G swap in ram with my regular 512MB memory speeds things up considerably.
Yes, her result is correct. Turning a 1G disk swap partition into an extra 1G of new ram used as swap will make the system speed up considerably. But only when compared to the previous setup of having 512mb and 1G of on disk swap. And not only that, unless she's a kernel hacker with significant experience (in which case she'd never have considered this silly idea in the first place) she will be unable to discern any performance difference between 1.5G RAM and 512mb RAM + 1G RAM swap. That's because the RAM swap will be of such a low latency that when she's watching how quickly she can start two large programs, the time difference between 1.5G ram and 512ram/1Gram swap will not be noticable to her by "watching the system". It will only be noticable and measurable by watching the execution code path, and by monitoring the cycle counter to see which one took more cpu cycles or executed more code. And I highly doubt she's experienced enough to be able to measure those aspects of her system to discern the difference between 1.5G ram and 512MB ram + 1G ram swap.
And since she failed to comprehend the true nature of swap and why it's there she never even once considered the solution that we all see as so totally obvious that we'd never have considered making RAM into swap. That of buying an extra 1G of ram, plugging it in, and letting the kernel use it as 1.5 GB of ram (old 512MB + new 1G). She seems to have begun from a misunderstanding of "must have swap, swap is required". But swap is not a must have or required item in a perfect world. In a perfect world, we would have, and could afford to plug in, sufficient ram on our MB's to hold everything we ever wanted to run, with plenty of space left over for large disk caches. But we don't live in a perfect world, and we more often than not do not have enough RAM to store everything we ever wanted to run. And that's why swap exists, to let us pretend our limited physical ram is a larger ram than we can afford, or a larger ram than we can plug into our MB's.
Then she goes and posts her idea publicly, and instead of receiving a chorous of "oh my, how wonderful" and "wow, what a great new idea", she gets a whole lot of responses of the nature of "this is so silly and stupid why would you ever even think about it". And so, to defend her "honor" she starts hiding behind "flat earth mentality" and "you didn't post any proof" and "you didn't post any benchmarks" and such. Which is where the insulting comment I overlooked above comes about. She didn't do her homework, posted her article, and then is accusing everyone else of not doing their homework when she's shown that her idea is not the great, grandiose, wonderful idea she thought it was at first. I'll let you connect the dots to figure out the "insult" that's available there.
Won't argue with you there
I'm in complete agreement. What I forgot to put in my original post was that for newbie techies this seems like a reasonable mistake. In this case the poster isn't so much the problem (tons of these must get posted every day) as the person who decided that this is front page news.
In the regal tradition of real life, I'd be more inclined to just say, "Whoops! Please be more careful in future" to both of them, rather than a traditional internet flame fest. It's no big deal.
My only real issue with the poster is he/she (I've met male Kim's) went wingnuts telling everyone who thought it was stupid that *they* didn't know squat. I'm also sure this person is very young and/or still has some maturing to do.
In the end, I was merely pointing out that the poster should, in future, learn from this and do a little more groundwork/proof gathering before proposing a controversial/stupid seeming idea. A good lesson to take away, I think.
Cheers
Do You Feel Better getting that off your chest?
"
Then she goes and posts her idea publicly, and instead of receiving a chorous of "oh my, how wonderful" and "wow, what a great new idea", she gets a whole lot of responses of the nature of "this is so silly and stupid why would you ever even think about it". And so, to defend her "honor" she starts hiding behind "flat earth mentality" and "you didn't post any proof" and "you didn't post any benchmarks" and such. Which is where the insulting comment I overlooked above comes about. She didn't do her homework, posted her article, and then is accusing everyone else of not doing their homework when she's shown that her idea is not the great, grandiose, wonderful idea she thought it was at first. I'll let you connect the dots to figure out the "insult" that's available there."
What's all this "great, wonderful, grandiose idea stuff"?
I just wanted to get this out so people can try it if they want. I think my intro into the article was enhanced a little bit for discussion group purposes. Did you actually read the article proper or just what is on the front page? Can you disagree that programs are getting larger, requiring more memory, and therefore more swap? That hard drives are not getting faster? That getting things swapped back in isn't taking more time? Certainly there were a lot of people complaining about swap-back-in times in the earlier discussion group about whether swap is necessary or not. Quite a discussion on that too. Maybe you were one of the participants?
The fact remains that RAM swap is the fastest available solid state storage that most everyone can afford (least expensive) and it is attached to a very fast interface, about the fastest one available in most everyone's computer.
Sounds like you are replying to some emotional issue here. You seem pretty upset.
You still don't get it, do you?
I just wanted to get this out so people can try it if they want.
Hello earth? There is no usage for other people to try what you've done. Numerous people have already explained this to you, but you still don't appear to get it.
Here's the situation from a performance point of view.
You have 1 GB of RAM. Okay? Well, now when we assume that's enought for you we say to the kernel "i don't want to swap" and then the kernel won't swap. Voila. Fast, but for some that 1 GB RAM is also quite expensive. (Gentoo users would together with a fast CPU love this, though.)
Now, if you only have 256 MB RAM on e.g. your desktop (like i have) and don't wish to spend money on (better) RAM or better hardware (better mainboard, CPU) then you'll gotta use swap if that 256 MB RAM ain't enough. Which is what i do.
Under no circumstances it makes sense to use that computer with 1 GB RAM which doesn't have swap as you did: mapping RAM as if it is swap space. If you were using your videocard's memory it would have been slightly more interesting but this has been documented already. So what's the purpose? There is no technical purpose for this. One is wasting his/her time with doing something like this. Might not be a problem for you, but i rather read interesting tech information than "fun" projects.
Statistics, or a project like this, is rather fun than productive. What happened is purely the result of logic. Frankly, i don't see the fun of it, because i find it completely useless, and many people agree with me on that point hence you get these reactions.
You don't have to view this as offensive as it is nothing personal and i'm quite sure it ain't personal from almost anyone who argumented similar as i do. The problem people have with you, seems to be that you're so stubborn not admitting the uselessness of your research even though it has already been argumented numerous times in detail why there is no purpose doing what you've done. Why don't you admit the obvious mistake? There's nothing wrong with making non-fatal mistakes (like this one) in life as long as you learn from it. I suggest you try doing that.
You still don't get it, do you?
Well, let's assume the starting situation is 512MB RAM and 1GB swapfile, and the swapfile must go due to performance and/or reliability issues. The total amount of possible storage of 1.5GB is enough in any real world usage scenario.
Choices:
1) Solid state disk
2) 1GB more ram, disable swapfile
3) 1GB more ram, user as swap space
Choice 1 doesn't make sense, it is so expensive and slow compared to standard RAM that it can't be justified.
Therefore 1GB more RAM it is (and the price of RAM vs HDD doesn't amtter in this situation).
Now, usage of said RAM seems to attract two types of comments:
4) RAM used as swap space: You are stupid, why waste RAM as swap, just use it as RAM.
5) RAM used as RAM: You are stupid, VM requires you to have some swap space for optimal performance.
Now, realizing that whichever way the solid state memory is used, it's no good for everybody, type 6 comments start pouring in:
6) Stupid! Use the RAM as RAM and enable a swapfile on disk.
Oh, well. And so it continues and continues from step 4 all over again.
I say choice 3 (replace mechanical swapfile with RAM swap space) is currently optimal: It is fast and reliable and doesn't affect the VM subsystem operation in any way. It may also be used as regular RAM after the truth behind type 5 comments is studied and possible problems solved.
Kmo
I say choice 3 (replace mecha
Optimal? I've seen no numbers which supported that. I've seen no alternative analysis (e.g. 1,125 GB RAM and 0,125 swapRAM). The test circumstances used by Kim are flawed as pointed our numerous times.
"doesn't affect the VM subsystem operation in any way"? But there is data swapped out to that place while it ain't necessary! Compare that to "The total amount of possible storage of 1.5GB is enough in any real world usage scenario." and it could have just stayed in RAM.
One can't solve possible problems. One can only solve problems. As for truth, well, what type 5 logic of what has been posted here do you doubt? Especially see page 2 and 3 (when using 90 comment setting).
I could say, in the same way as Kim does, that i HAVE ran swapless RAM-only servers. I got money while doing that, and if something would have gone wrong i'd got my ass kicked. That never happened though.
You still don't get it, do you?
Oh, please. I'm not talking about mine, yours or anybody elses setups, just generally observing the situation and funnily contradictory comments for and against of various choices. I'm not trying to push my opinion on anyone, and I can make my own mind respectively.
Anyway, the question was about replacing a mechanical disk with RAM. If the added RAM is used as swap space, it is a hell of a lot faster than the replaced disk. On the other hand it doesn't risk in any way any changes to the VM operation (memory area partitioning, priorization, graceful degradation, etc).
Therefore it is a minimal change from the starting situation, a lot faster, more reliable and absolutely safe choice with no risks at all. In other words it only has positive influence into the system and can not have any negative side effects, meeting the original goal of a simple performance/reliability boost.
There is no need for further benchmarks and proofs of what could be achieved if this and that was tuned and done, squeezing every last drop of performance out of certain setup and usage pattern is an entirely different issue and not the goal in this case.
As a side note, a bit more open minded approach and consideration for bigger picture in general (instead of quibbling about irrelevant minute details) is usually a good basis for fruitful discussion.
Personally, not getting down to specifics, I think Kim has made an excellent article, based on controversy and amount of comments it has raised.
Cheers, Kmo
Hi Kmo, Consider kmerley w
Hi Kmo,
Consider kmerley wrote:
The fact remains that RAM swap is the fastest available solid state storage that most everyone can afford (least expensive) and it is attached to a very fast interface, about the fastest one available in most everyone's computer.
Which was the part i was mostly replying to because she hasn't proved what she says. She hasn't considered a simple, logic and solid solution: RAM as RAM. She has not researched wether it is as fast or usable as the one she has researched yet she says about swapram: fastest available solid state storage and says that most everyone can afford (least expensive) whereas the RAM-only solution is exactly as expensive as swapram. Moreover she claims and it is attached to a very fast interface and about the fastest one available in most everyone's computer. While that last quote may be right (because of "the word about which leaves the RAM-only possibility open), she evaded a simple, logic and solid solution and has not researched why it ain't working for her as intended yet she argues here over and over again her solution is the solution. This is quite annoying, as it is misinformation. She also showed she has little knowledge about swap and the Linux VM which lowers her credibility. Hence, i do not agree with I think Kim has made an excellent article. Also, based on controversy and amount of comments it has raised. does not indicate anything; one could just as well argue it is because of her shortsightness. Trolls, misinformation quite often lead to controversity itself leading to lengty discussions.
Therefore it is a minimal change from the starting situation, a lot faster, more reliable and absolutely safe choice with no risks at all. In other words it only has positive influence into the system and can not have any negative side effects, meeting the original goal of a simple performance/reliability boost.
..but a much more simple solution is evaded because of some magic flickering she experienced while she experienced that too on systems which did not have RAM-only setups.
There is no need for further benchmarks and proofs of what could be achieved if this and that was tuned and done, squeezing every last drop of performance out of certain setup and usage pattern is an entirely different issue and not the goal in this case.
To proof this is the best and only solution (which she again claims in this post), there is as a much more simple and easier solution lies at anyone's fingertips. Why make simplicity complex? Why only research how X is a solution to problem Z, and not Y? That's not user-friendly. That's not unbiased, or scientific.
As a side note, a bit more open minded approach and consideration for bigger picture in general (instead of quibbling about irrelevant minute details) is usually a good basis for fruitful discussion.
Consider i've been waiting for a less biased, more scientific research for quite some time while seeing my, and other's constructive arguments fundamentally beeing ignored. For example, because the author is "Anonymous" it somehow doesn't carry weight.
I'm very open-minded to any numbers or scientific research regarding this, i mostly welcome it! But, basing myself on a biased research, and misinformation where newbies trap themselves into, is something i oppose. If that makes me closed-minded, so be it. Couldn't care less.
Also, consider i have run RAM-only setups with Linux 2.4.x with no stability issues and without the complexity of Kim's solution.
Kmo, I like your comment
This is a great comment describing about all the comments. It is kind of like a jazz group, and everybody wants a solo, maybe more than one. It is the same tune and has a few verses, and you keep doing the song over and over and each time there are little variations. That is like life on earth. There are a few basic types of lives, and everybody just keeps living them over and over with small variations. But I digress.
Yes, and I have been waiting for some respected kernel contributor to give the no swap option a clean bill of health. I haven't seen that yet.
But I like your dispassionate analysis.
Respected kernel contributor for an arrogant bitch?
Uhm, what kind of pseudo-psychoanalysis is this?
It is the same tune and has a few verses, and you keep doing the song over and over and each time there are little variations.
Please, get some self-reflection. If the above is true, then it also counts for you.
More important, the burden of proof lies at you because you've not proven anything because your research was biased.
I am still awaiting a clean bill of health on swapless
Nothing personal. I am still awaiting a clean bill of health from the kernel contributors. Instead what I see from them is reasons to have swap. They say if you have swap, it allows this good thing to happen. If you don't have swap, these not so good things might happen. They say you might get rid of the swap latency, but may intorduce other latency by having to get data from the hard drive that would have already been in memory if you had swap.
But, maybe all you no swap guys know more than they do.
No, its not personal. Its dis
No, its not personal. Its discrimination and lack of respect to anonymous users. Why don't you ask what one's profession is. I've never seen you asking it. You could just ask it to some of the anonymous posters. Even though i'd argue its the argument which matters, not who says it.
If i don't have swap and i have enough RAM then my system is in perfect condition. None of your rants proof otherwise.
But, maybe all you no swap guys know more than they do.
I'm afraid i do on specific fields, namely science, programming and computer-related. How old are you? What's your background? What's your profession?
1st april?
How does this make sense?
I mean you could use the swap space in RAM as -> RAM.
An then use a harddisk for more swapspace.
You usually use swapping, because you can have _much more_ virtual memory than RAM.
I don't understand it.
re: 1st april?
It makes sense because the later Linux kernels do not use the RAM as well as they should. They swap when there is plenty of RAM available, which is clearly annoying. By having the kernel use swap in RAM, you are band-aiding a problem with the current VM.
"My results were 30 seconds t
"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."
Could you please post the scripts and explain the methodology you used to gather these timings ? This way an independant run could be done by everyone else to verify the results. When you post test results and want to be taken seriously, there is no other way.
If everyone see the same results, then there is a flaw in the VM, if not, there is probably a flaw in your methodology (not enough runs, lack of precision of the tools you used or lack of control over the background tasks running on your test systems for example).
The scripts are in the article
The scripts are in the article for 2.4 kernel swapram. I just opened enough programs until half or 2/3rds of swap was filled. Then just clicked on programs that had been swapped out. If it took 30 seconds, it was swapping back in, if it took less than a second I assumed it was not swapping back in. A simple test, factor of 60 difference. I suppose your mileage may vary. It was on a 1.2 GHz Duron with a GB ram, 7200 rpm drive of 60 GB last September using FC1. I also tried it on a 1.5 GHz P4 with 1 GB Debian 3.0, 2.4 kernel, a 500 MHz AMD with 256 MB (didn't help much) and a 400 MHz Dell Laptop with 128 MB (didn't help at all, hardly enough ram in the first place).
Base example of how to test
I saw the scripts to create the swapram, what I asked is what scripts did you use to get the timings. Clicking around on a 100+ processes system isn't really something that you can reproduce.
With your method you can surely spot 60x difference, but you can hardly argue that this is enough to accurately spot reproducible 0,5s to 0,75s delays.
The swap vs no swap desktop performance is a well known problem (at least by VM hackers) with 2.4 kernels and 2.6 not tuned with swapiness, but this isn't your point, is it ?
As I understood, your main point is : "you should use some amount of RAM as swap to solve perf problems instead of using no swap" (the title is "How to Use RAM as Swap", isn't it ?), you definitely have to do better than that to prove your point.
Hint :
- write a simple memory hog program (one text-based that allocates a command-line configurable amount of memory, then read the whole malloced array on each keypress and report the time used to do so),
- boot in console mode with no background processes (tweak your runlevel 3 if it is what your distribution uses as console level),
- log on 3 text consoles,
- launch your memory-hog on 2 of them,
- read a big file in the third to stress the cache,
- switch consoles and press a key to have the processes report the time they spend reading their malloced array (coming out of swap if needed).
1/ Boot on a 1GB system with mem=512M and 512M swap, launch the program with a malloced array of 300M, read 300M of files (you can use grep on a 300M file).
2/ Do the same with no mem= parameter to use all your RAM,
3/ same as above but with swapram using 512M.
Change the values above as much as you want (this is a short example, you may find many interesting things by changing the amount of disk reads or size of malloced arrays).
Do a nice html table with the results, output of free before and after runs, and output of ps aux.
Then you'll have something to talk about. Now there's to much smoke.
Exactly
This is why there are so many comments on here of the order of "she didn't do any proper testing either".
Her test amounted to clicking on x-window title bars and maybe using a stopwatch to count how long it took before the app was on top and usable.
Then switching from swap on disk to swap in her newly purchased ram chips.
Had she done, and posted, a test sequence like the above, then her results could be reproducable by others to verify. But simply clicking around on title bars provides nothing beyond the clearly obvious result of yes, swapping to ram is faster than swapping to disk.
This is why there are so many comments to her comments of "no one has done any tests" pointing out that she has also not done any real verifable tests either. It's just a "feel".
And, much like the few folks who pay $600/ft for speaker wire, after you've put in the effort (or paid he high price), there's an effect where one wants to belive so badly that their work (or expense) wasn't in vain that we refuse to belive it didn't make a difference and is clearly better.
And again repeating the clicking on x-window title bars and maybe using a stopwatch to count how long it took before the app was on top and usable.
This is not a scientific test, and proves nothing more than the rest of us have been saying, swap in ram will be faster, yes, but it's still a silly idea vs. letting the kernel use all that ram as it sees fit.
"letting the kernel use all that ram as it sees fit."
"letting the kernel use all that ram as it sees fit."
The assumption here is that the kernel has no flaws and always chooses the best way to do things, well, at least until the next patch.
The assumption a piece of sof
The assumption a piece of software does not contain bugs, more specific "letting the kernel use all that ram as it sees fit" is true in this case. This assumption counts for software in general and for life in general. I assume that when i drive on a bicycle, the car which passes is not having a mechanical problem which causes it to get off the road, possibly hitting me during the effort.
However, your pseudo-scientific analysis, or rather, the lack of that, has not debunked or pointed out the software in this case, Linux, has a flaw. What you have only done is raising questions and mostly raising questions regarding you and your pseudo-scientific analysis rather that the Linux kernel.
Some people call this FUD or astroturfing.
Personally, i have experience with running a stable, swapless, swapramless servers with only (enough) RAM as i've already stated elsewhere. In no case i have experienced vague consequences by doing so. There is no condition on which the premise between your screen flickering event and the RAM-only condition is pointed out hence there is at best a relation in your particular situation however no correlation. Why do you think bugs have to be reproduced? Why haven't you tried some of the possible solutions to see if these solved your problem? Why haven't you redone your analysis on scientific conditions after several innocent bystanders pointed out flaws in your article? Why does it appear to be so hard for you to admit a mistake? We don't even know you! It's the Internet!
Really, i don't get it. Frankly, i'm getting quite sick of all this FUD about the Linux kernel, and pseudo-scientific rambling, but i'm not giving up my cause to warn the reader about it.
A failure to understand
The writer of the article fails to understand the true purpose of swap. The true purpose of swap is to allow the kernel to empty fast RAM of unused or little used pages, so that the kernel will have more fast RAM available in which to store often used pages. That's it. There's nothing magical, nothing "special", nothing "white hat" about it. It's simply somewhere the kernel stashed less often used memory so that more RAM is available for other uses.
What the writer is proposing is now taking part of that fast RAM, and converting it into a storage location for unused or little used pages of RAM. But wait, if swap's usage was to remove pages from RAM, so that RAM can be free for other uses, then simply moving a page of memory from useful kernel RAM, and stuffing it into SWAP RAM, does not really help much. Because one page of ram is still consumed somewhere, either as main, or as swap, but RAM usage is identical in both cases.
The writer failed to explain the full setup of his system. If he origionally had 512MB of RAM, and a 1GB swap partition, and nothing more available (no more SWAP anywhere), then from the kernel's point of view, he had 1.5GB of memory. Only 512MB was directly useful to the kernel, the rest has to be moved back and forth from disk. But, this also means that the writer could only run enough programs to consume a total of 1.5G of memory, after that, the kernel would start killing tasks to free memory (out of memory situation).
If the poster could afford to buy an additional 1G of RAM (it's not that expensive anymore), and only needed 1.5G total, his best solution would have been to plug that ram in as main kernel RAM, so the kernel has 1.5G of ram, and stop using swap all together. This way, all 1.5G of ram is useful for processes, as disk cache, or directory cache, or anything else the kernel chooses to use it for. But by making the extra 1G of RAM into swap, all he's done is produce a system that is almost, but not quite, as fast as if it had 1.5G of ram available as main kernel ram. The reason why it's almost, but not quite as fast, is that because physical RAM is just as fast as physical RAM, his swap latency will drop to almost zero. The kernel will be able to swap a page in/out to RAM swap almost as fast as allocating another page of ram. But the trouble is, it's almost as fast, because they kernel goes through the entire "allocate from ram" code path, discovers nothing free, and then has to execute the "find a page to swap and copy it to swap" code path to free something up. If he'd had 1.5G of real ram, the "allocate a page from ram" code path would likely have found something already free, and it wouldn't have needed to let the "find a page to swap and copy it" code path's execute. Additionally, to swap to RAM requires the CPU to do a copy from RAM to RAM, this, even on modern CPU's, is still a somewhat expensive operation, and will take a bit more time than simply locating a free page in RAM and allocating it (plus the "locate free page" code path's already been run, remember, otherwise, how'd the kernel know it was out of memory.
So, to summarize, unless you just like playing with funky new and unique arrangements, don't bother doing what the writer suggests, it's based on a fundamental misunderstanding of the purpose of swap on the writers part. If you have 1.5G of memory as 512mb ram and 1g swap, and you end up making use of most of the 1.5G of memory by allocating it to something, and you buy an extra 1G of ram, you are much better of simply using the 1g of ram you just bought as memory, and turning off your swap. Or if you want, since the partition's likely already allocated, go with 1.5G of ram, and a 1G swap.
And to answer someone question before they answer it, what about when he turned off swap and things got jerky. Well, remember, he had only 512MB of ram, and 1G of swap. When he turned off swap, the first thing the kernel did was move everything allocated into swap back into RAM, and in the process he probably filled his ram up with process pages such that he had only a tiny amount of disk/directory cache memory left. That's why things got jerky. He was witnessing directly the latency of mechanical storage (disk) because there was no leftover ram to cache (and smooth over) the latency of mechanical storage. This again, was also a fundamental misunderstanding on the writers part.
Not quite right
There was a reboot between the two test cases. Well this looks like a case of call it too complicated to ever figure out, and then maybe we won't have to deal with it. Make it the province of the initiated only.
No swap does run as fast as ram swap. There is just some problem with not having any swap. I don't know that you have enumerated it.
there is no problem with not having any swap
I think I've just spotted your problem. You have a fixed idea that "There is just some problem with not having any swap."
I can assure you, there is no problem with not having any swap. Try it. Turn off your disk-based swap (you have done that already) and turn off your RAM-based swap. Make your tests again. And tell us if you'll have some problems. 2.4 or 2.6, neither of them have problems running without swap.
Though, adding some swap improves performacne (in troughput terms) but, self evidently, increases latency as well.
Robert.
OK, I would except I just like that smoother feel
Robert, thank you for making it so I can tell which anonymous you are. And thanks for your sincere comments, even though you disagree.
Just shutting off the swap is definitely a lot easier, no two ways about it.
Kim
"A failure to understand"
In 2.4 kernel it doesn't matter if you add another 1GB to 512 MB RAM, because in just a few hours, much will be swapped out. When you request something that has been swapped out, you will have to wait. If it is a server, the client will have to wait. I suspect that some of the waiting for internet pages is waiting for something to be swapped back in to a server.
Try it. Start with 512 MB of RAM and swap on hard disk. Pretty soon all but about 5 MB will be used in caches and buffers. Add another GB of RAM, and don't change swap, and that will be filled up with caches and buffers in some hours. You can certainly run more programs at the same time with 1.5GB RAM, verses .5GB RAM, not changing swap. But, the kernel (2.4) will still start swapping out applications that haven't been used for a while, and a while in server time might not be very long.
So, there will be latencies with either 512 MB or 1.5 GB whenever you have to retrieve something from swap. And the 2.4 kernel will swap out some things you will need later.
If you never notice this, then swapram is not for you, so don't worry about it.
"A failure to understand"
Sigh, and again, you fail to grok the point.
Your origional setup: 512MB ram + 1GB swap on disk.
Total memory available to any and all programs: 1.5G. (keep this number in mind, it will be important later)
Your newly purchased ram upgrade: 512MB origional ram + 1GB new ram
Just counting ram (semiconductor chip memory): total memory: 1.5G
In your old setup, you had a total of 1.5G of available memory of any sort. So therefore, 1.5G of total memory must have been enough for your use of your machine.
In your "upgraded" system, you now have a total of 1.5G of memory, only this time, the whole complete 1.5G is all semiconductor memory, no disk memory has been accounted for yet.
So, your new systems total ram (before considering swap on disk) is equal to your old systems total sum of ram and disk swap. If 1.5G of total memory was enough for your purposes, then what you should have done was simply turned off your 1GB swap partition, and just let the kernel manage the 1.5G of memory as it saw fit.
This would have given you least one advantage: The kernel is by far better than you will ever be at deciding how to balance memory usage out amoung all the competing requests for memory. Why, because it's responsible for that, you just touch the keyboard/mouse, you don't directly make the decisions of "do this with ram, do that with this page of memory," etc. Sometimes the kernel might use it for disk cache, sometimes the kernel might use it for process memory, sometimes it might get used for shared memory between processoes, but it's up to the kernel to decide.
When you decided to go and convert the new 1GB of ram you added into swap, you essentially tied the kernels hands. You now forcefully told the kernel, I want you to use this new 1GB not as you best see fit, but instead, only use it for swap. And now, that's all the extra 1GB can be used for by the kernel, swap and swap alone. The kernel can never decide to use 50% of that extra as disk cache some of the time, and use it as shared memory at other times. You've told it you know better, and you want it used only for swap.
That's an inefficient use of your new resource (the extra 1GB of memory). You've limited the kernel to only using it one way, when if you had just let the kernel see all 1.5G as ram, the kernel could have used it any way it saw fit.
Secondly, if you don't like waiting for a seldom used process to swap back in from swap, and you've now built a machine with total ram equal to your old ram + swap, then simply turn off your swap partition. Just like magic, if you turn off the swap partition, guess what happens. The kernel stops swapping idle tasks out to the swap storage space. With no swap space allocated, there will be no swapping. You'll enjoy the exact same performance improvement (actually, it will be a little faster because rather than having to first copy 250Meg of open office binary from swap(in ram) to ram, it can just start executing it immediately) and you'll never see a latency issue because the kernel decided to swap something unused out to swap for you to better utilize your ram for something else more important.
The above point was one of the subtle failure to understand points you missed by not researching what swap is, how it works, and why it's there. Programs do not execute directly out of swap. They must be copied from swap into ram (ram that's used for execution) first before they can execute. If you have 1G of swap in ram, then everything that used to be copied off to disk in your old setup will eventually, at some point, end up copied off to swap in ram. When you then go to use it again, it will first have to be copied back from swap into ram first (the actual operation is more complex than this, but I'm deliberatly keeping it simple for you, the copy part must always happen). Copying a program from swap in ram to execution ram will take some finite amount of time. It will be less time than copying that same program from disk swap, but it will still take time. If instead, you had a whole 1.5G of execution ram, and no swap (so the program can't be pushed out to swap), there's no copy step (because the program was never moved out of execution ram). The kernel just starts executing the process you've chosen to interact with again, and all is well.
See the point yet? If you don't like waiting for programs to swap in from disk, then buy enough RAM to equal your old total of RAM + disk swap (which you did), and turn off the disk swap partition. Then you never have to wait for any active program to swap in from disk. But don't turn all that nice new wonderful ram into a creakey old replacement for your old disk swap partition.
Clueless..
How the heck did this nonsense ever make it to the front page? The best way to "swap" is to have enough main memory such that the system never swaps. Just plug the memory in and use it as general purpose memory. And turn off the disk swapping if that bugs you. The results will be WAY better than trying to partition memory into swap and non swap.
Read through how Linux manages memory, too. It could help prevent foolish articles like this one!
Cheers
Linux will always swap (in 2.4 anyway)
Linux will always swap if swap is turned on
What about compression?
Having read the other responses most are in agreement that there is no benefit from having swap in RAM. BUT, what if you could compress each page of memory before comitting it to ramdisk; many programs allocate more memory than they need, or use sparse data structures that would compress exceptionally well. Even binary executables compress 2:1 so there is no reason why the memory souldn't show the same characteristics.
1GB of memory could then be used as say 750MB memory and 256MB of swap which may be able to accommodate up to 1GB of paged data due to the data's sparsety.
CPUs today are so fast that (I suspect) compressiong 4MB of data and writing it to ramdisk would still be significantly faster than paging it to disk.
I don't know how easy this would be to impliment; it would be nice if one could just run a compressing filesystem on the ramdisk but unless each page is trated as a separate file this would not be possible.
OK, this is the point that I start speculating and recognise I need to bow down to more expert comments.
Paul.<><
Little out of date but maybe
Little out of date but maybe still interesting project using this idea:
http://linuxcompressed.sourceforge.net/
What about compression?
If she had done something like this, then, yes, her idea might carry some weight. Because the result would be the intended purpose of swap, that being to create some free memory to reuse for another purpose. By compressing the pages before they were committed to ramdisk, there would be a reduction of total RAM used, creating free memory in the process. And then, later, if the system wanted to, the compressed pages could themselves be moved out to disk (which would in effect increase your effective disk bandwidth almost by the compression ratio).
But, this wasn't what she came up with. So her idea does not do this. She either has 4k of memory in RAM consumed, or 4k of memory in RAM consumed. It's still 4k=4k. But in "kimworld" 4k of RAM is not the same as 4k in swapram.
Paul, I like this idea of compressed swapram
I am just going through, kind of randomly, many of these comments. I like this idea. I don't know how to do it though, not yet, having not thought about it. There are probably some reading here that could do it. It would take some space in RAM while the compression was being done, but it could sure be released. And also for the decompress.
Some data doesn't compress very well, other types compress a lot. What is the average compression that could be applied to swap? Probably a fair amount, especially if the swap control algorithms concentrated on swapping compressible data.
But this is a great idea. I didn't think of it, it is yours.
Kim
I give it a try
At first glance, I laughed. Accessing directly a page will always be faster than copying from a swap on a file on another page (you have to go through the VFS and ext2 code too!!).
Then some comments assumes there was a bug in Linux way of handling the memory, and that the swap presence was really intrusive. Maybe. In such a case, this thing would have shown a real bug in the VMM code.
Some other comments said opponents didn't have given a try to this configuration. Well, I did it.
Now I have tested, I can say: it completely sucks on Linux 2.6.8.1.
I have 512MB and splitted it in two parts: 256MB for memory swap, 256MB for normal memory usage. Then I started KDE (Kdevelop, 2 konquerors, knode, kmail, korganiser, umbrello, 5 konsole, kstars, ran noatun on a movie...), OpenOffice, untarred linux sources, loaded some documents and managed to fill my memory (this was obviously enough).
The machine literally crawled under pressure, kswapd froze the system for several seconds while the IO on disk was done, sometimes switching from one app to another took more than 2seconds. First fact.
I then rebooted without ramdisk, and without swap (therefore with 512MB for normal use). Everything ran ***very*** nice, the memory wasn't even full. Second fact.
I didn't tried with Linux 2.4. But I don't think there is any reason it should behave far better than 2.6 under low memory pressure.
So computer science is not so strange than it was supposed in this thread. And what should happen really happens. When you take 50% of your memory, you will have sooner memory pressure. Forcing the system to swap **what it can** swap, ie text sections of applications, pushing the CODE on disk instead of potential less important data it would have swapped with swap enabled. I didn't tried to stick all my applications to memory with chmod, since this test was enough for me to show that it was useless. Please note that Linux will never swap text sections to memory if there is only a memory swap: it will swap it to the original object file.
May my test be taken into account before saying memory swap opponents have chosen definitively their camp.
I suggest the writer either to upgrade to 2.6, whose VM is more tunable, or check its hardware if he really has better performance with RAM swap than no swap at all.
Bye,
CC
Yes, this wasn't tested on 2.6, just 2.4, until you did it
At least there is some data. Might be a lot different in 2.6 as the VM controls are a lot different, and swappiness has been added.
I give it a try
The reason (and the only reason) it worked for our Kim, is that she went from a first system like so:
512MB RAM + 1G disk swap space
to a system like so:
512MB RAM + 1G of RAM holding swapspace
Now, it does not take a rocket scientist to recognize that replacing 1G of disk swap space with 1G or ram swap space will in fact produce a faster system. Simply because 1G of ram swap space will have much lower latency and higher bandwidth than 1G of disk swap space.
So in fact, all she discovered is that if you replace disk storage with an equivalent sized RAM storage, things will be faster. But that's always true.
But what she's steadfastly ignored, and refused to even consider, is the fact that it's a whole lot simpler, faster, less error prone, and easier, to replace 1G of disk swap with an extra 1G of RAM, and turn off the disk swap. Same speedup advantage (the old 1G of disk storage is replaced by a new 1G of RAM storage), and elimination of the problem she felt was bothering her (swapping).
The other problem that she's failed to recognize is that if someone listens to her claims that "put your swap in ram, it's faster/better/etc." and does not do what she did up front (buy an amount of extra RAM equal to your old swap space), then that someone is going to discover what you discovered. It will suck. But sadly, she's not concerned that she might lead people astray, and have them create convoluted systems for themselves that actually hurt them in the end.
The "secret" to her success is in the buying of the 1G of RAM. Much like any magic show, once you realize where the "trick" is, the rest is just illusion. In her case, the "trick" to the whole mess is the purchasing of extra memory equal in amount to your existing disk swap space.
One thing
So in fact, all she discovered is that if you replace disk storage with an equivalent sized RAM storage, things will be faster. But that's always true.
Not necessarily. Only if the added RAM will be used while it was swap (or not enough memory which lead to crashes of applications). Adding X MB to a 1 GB server which only uses 512 MB RAM at max and no swap adds nothing to performance. Only to insurance apps won't crash.
The above however doesn't apply in Kim's situation and in reality it'll not apply in many situations either. I agree with the rest you said. Thanks for posting that.
another analogy+=
The advantage of Swap in RAM to just RAM (sytem without swap) is NULL.
If you have enough RAM it !!may!! be that slightly faster if u give bout 128/256 for swap in RAM or it also may be slower. But that difference would be microseconds. So its almost 0.
Written in the Analogy:
Just keep increasing your Desk, so all you need fits onto ...
So if you afford +1Gb RAM, just leave it as RAM, as long as you run without swap. If you insist on running with swap, the swap in RAM should be right (at least 2.4/2.2, dunno bout 2.6 (yet) ). (But who insists if it works without too ..)
ram disk as swap
Good article.
This type situation happens when you have machines with multi-speed memory or systems where some of the memory must be accessed via a "special" method like paging. Older IBM mainframes have low memory and high memory. High memory can not be addressed as direct access ram under linux. The only way to use the high memory is as a ram disk. In those cases you must use multiple swap areas. The less used pages migrate out to disk and the more active pages stay in high memory more often.
This is a tool every good sys admin should know about for cases where you NEED to thottle those LARGE memory hogs while still doing your best to provide service.
This is definately a tool to TRY when you have a machine fully committed (no idle time for hours) with more load piling on and no chance for faster hardware.
Your workloads may vary. Swapping is never a good thing for performance, however, WHEN your load forces you into swapping it is possible to use this method to minimize thrashing (by throttling the memory hogs) and still get MORE total (useful) work done.
Measure your system, change the system - measure again. It the change resulted in an improvement keep the change otherwise back the change out and try try again.
thanks for the tip
keep up the good work
oscar
Re: ram disk as swap
>Older IBM mainframes have low memory and high memory. High memory can >not be addressed as direct access ram under linux
You mean the kind that can't run Linux anyway?
>This is a tool every good sys admin should know about for cases where >you NEED to thottle those LARGE memory hogs while still doing your best >to provide service.
No its not. It provides no value whatsoever. It completely defeats the point of using swap.
>Swapping is never a good thing for performance, however,
That's just not true. You do know that OS's like VMS function so well when lots of users are using the system with pitful amounts of main memory because they have smart swapping algorithms, and make good choices about what they swap/page to disk and when, right?
The Linux kernel also has pretty good swapping algorithms too (at least in later 2.4 kernels and 2.6 kernels). Though it is misisng some VM-related things I'd love to see like working set extents/quotas, per-process resident segment size limitations, ability to carefully tune where it switches from on-demand swapping to per-process swapping, and the abiilty to have growable swap spaces.
This whole swap is bad thing is just a myth. Swap is a good thing, almost always, except in some very well-defined corner cases.
It allows memory that isn't being actively used to be released so programs that need more memory can use it.
Nevermind this article is probably the dumbest thing I've ever seen in my life. Putting swap on RAM provides no benefit whatsoever to anything. It actually probably hurts your performance under duress, because you've added overhead and artificaly constrain the VM's options.
More main memory is always a good thing, never bad. So why would you take some of it away to use as swap? There's just no logical explanation for it.
another Analogy:
The advantage of Swap in RAM to just RAM (sytem without swap) is NULL.
If you have enough RAM it !!may!! be that slightly faster if u give bout 128/256 for swap in RAM or it also may be slower. But that difference would be microseconds. So its 0, if RAM is still big enough (i do not even think about having 512 splitted by half ... RAM should in this case be quite more than swap ... )
Written in the Analogy:
Just keep increasing your Desk, so all you need fits onto ...
So if you afford +1Gb RAM, just leave it as RAM, as long as you run without swap. If you insist on running with swap, the swap in RAM should be right (at least 2.4/2.2, dunno bout 2.6 (yet) ). (But who insists if it works without too ..)
On the wrong track from the beginning?
Hi!
I was just wondering this whole debate. My feeling of this swapping to memory is that someone just wants to prevent the file cache of eating all the physical RAM. Better way would be to limit the maximum size of file cache.
In essence, allocating physical RAM for memory swapping does this, but is somewhat sub-optimal as accessing the memory swap raises page faults leading to memory copying (I think this is not eliminated in current kernels). This is naturally waste of resources.
As pointed out in previous comments, disk swaps are beneficial as unused memory tends to get there. But the case which we want to prevent is that when doing large file reads and writes (eg. cp big_movie.mpg some_dir) we don't want our mozillas and gnomes to get swapped out. Limiting maximum file cache size should prevent it.
]S[
Addendum
When the memory is not uniform in access speeds, or cannot be accessed directly, memory swaps are useful, ofcourse. Fast memory for program memory and slow memory for swapping, etc.
Fast/slow memory is the case with P4 and more than 4GB of memory.
If you know how, please tell us
I want to know how to prevent file caching from eating all the physical RAM. How do you do it? There doesn't seem to be anything in 2.4 to do that. Is there? Someone please answer.
dentrificus totallis
so... if you dont keep swap these "dirty pages" occupy precious ram; and i assume that if you keep a swap then they are stored there... until they overflow back and occupy precious ram ;-)
..and i also assume that when you flush the swap (swapoff-a) these pages have nowhere else to go but to /dev/null (i'm on a long shot here.. assuming this)
now say we keep 15% or ram for this ram-swap; and periodicly flush it (swapoff -a; swapon -a) =)
would that not solve the problems?
-------------------------------
t00Rman; spitting bullshit since 1999
> I want to know how to preve
> I want to know how to prevent file caching from eating all
> the physical RAM. How do you do it? There doesn't seem to
> be anything in 2.4 to do that. Is there? Someone please
> answer.
File caching will only use unused RAM. Let's take an hypothetical example:
You have 128MB RAM of which:
4MB is used by kernel code
78MB is used by userspace ("system" + users programs)
the 48MB left is used for cache.
Then user johndoe starts a program called "bigfatprogram". That program load it's data right on start and grow to 40MB in size. What the kernel will do is just drop off 40MB of it's cache so that bigfatprogram will fit right away on start, no swaping needed.
However, if bigfatprogram grow too much, the kernel will still keep some cache when it starts swapping unused mem. You want this because eating-up all cache memory will slow a lot your system...
I hope this will clarify a little about memory usage in linux...