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
Nick Piggin seems to think swap should stay
While you are at it, you should take a look at this:
http://kerneltrap.org/node/view/3000
Your solution gets nothing out on the disk. It just moves it from one section of memory to another section of memory.
Repeat after me: "I don't need swap"
> Well it is a magical property of swap space, because extra RAM
> doesn't allow you to replace unused memory with often used memory.
Aaaargh! If you still have unused memory left, you don't need swap!
> The theory holds true no matter how much RAM you have. Swap can
> improve performance. It can be trivially demonstrated."
But it cannot be demonstrated that replacing perfectly good memory by swap improves performance.
Why am I still trying to make you see reason?
Also interesting in this context.
Also interesting in this context, given the author's inability to argument, is "The Atheism Web: Logic & Fallacies", explained at for example infidels.org as referenced to. It explains thoroughly in detail what logic is, what it isn't, how it works, what it isn't, and how a constructive discussion is held. It also addresses a number of fallacies, helping an individual detecting them. Although infidels.org is about atheism and skepticism it is still a valuable read even for religious individuals. Kim, i humbly suggest you read it.
Jeremy
The example script in the article is correct, but in transcribing and changein it for the example in the article I left our the filename in step 5). It should read:
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"
The change is the addition of /sw at the end of the of= part of the commands. Without that change this part doesn't work. It is OK in the sample script, though. Thanks to the person that pointed this out. I would like to be able to correct this in the article. I have emailed this.
Kim
While you're at it...
If you insist on doing this, at least use the following script. It has exactly the same end result, except it is shorter, cleaner, and doesn't have the unnecessary overhead of ext2 filesystems in the middle...
#!/bin/sh
START_RAMDEV=2
END_RAMDEV=10
for i in `seq $START_RAMDEV $END_RAMDEV`
do
mkswap /dev/ram$i
swapon /dev/ram$i
done
While you're at it...
Actually, looking back now at her provided script, anyone with experience, such as the fellow anon. who posted the above script, can also see it has noob written all over it. Only a rank beginner would write a script where they wrote out each and every command, only to change a single number at the end of each /dev/ram? entry.
Thanks anon, you did in 9 lines (counting the blank) what took kim 63 lines to produce.
And I still have not yet figured out her attachment to swap files. I wonder if her 1GB of swap on disk was allocated in 8 different swap files, all quite fragmented over her drive. If that's the case, then it may be no wonder that swap seemed an order of magnitude or two slower for her than the rest of us. And if she left all 8 swap files on disk at the same priority, the kernel would then gleefully have round-robin accessed them, creating a severe head seek problem for her on swap usage.
How about it Kim, care to post what was the output of "swapon -s" on your system before you made any of your changes (i.e., when you had 512MB RAM and 1GB swap on disk)?
No, there was only one swap hard drive partition
It is better for desktop users (many are noobies as you like to call them) to not run into this attitude that you so clearly display. You are not helping the adoption of Linux with this attitude. But it is the most common attitude displayed to noobs by the very people that could help them, but don't want to. On the other hand, maybe you prefer Linux adoption on the desktop to be slow. You are doing your part.
You are not helping the adopt
You are not helping the adoption of Linux with this attitude.
You assume the author wishes Linux becomes more adopted.
I'm not the author of the comment you're replying to, but i do know Linux users who'd rather prefer ignorant users who don't wish to learn and prefer uber-slick-laziness GUIs to stay on Windows or MacOSX instead.
Not every Linux user is a zealot, too. Imagine you'd run YOUR business on Linux and are saving money while doing it. Would you advise your competitor to do the same or would you wish to keep that edge you have? Opinions differ, i can guarantee you that.
Personally, i don't have an outspoken opinion on this issue (issue?). My point is assuming a Linux user or more accurate a Kerneltrap.org reader prefers Linux to be adopted is... an assumption.
Also, in this case it doesn't really matter since there is no correlation between that and the subject itself which readers appear to discuss. Yet another fallacy from you. Multiple fallacies, as i see it, because you ignore the actual points of the author including How about it Kim, care to post what was the output of "swapon -s" on your system before you made any of your changes (i.e., when you had 512MB RAM and 1GB swap on disk)? You completely ignore that! You don't even say no to it. I'd rather see no, because [...] ofcourse.
No, there was only one swap hard drive partition
Actually, for desktop adoption, there are certian things that noobies should avoid because they are pitfalls that can create gatcha's that leave them with an inoperative system. Instead, they should read and research first, before they attempt making any changes. Playing around with their swap allocation, creating ramdisks out of part of their ram, and making it all work is something that they should avoid doing to their system until they have done their homework and understand the consequences.
An analogy is in order. Assume you own a car (if you do or don't own a car is irrelevant to the analogy). Second, assume you do not know how to perform any maintenance on the car you own. You are now in the same situation as a noobie with Linux. You own a complex machine (car / computer) and you do not know how to perform maintenance upon that machine (car / computer). Now, assume that one day, you decide you want to make a performance enhancing modification to your car. Now, do you immediately raise the hood and start switching parts, do you call a mechanic, or do you study up on auto repair? Remember now, you are assuming you don't know the first thing about auto maintenance. Well, you'd call a mechanic or study up on auto repair, obviously. Why, because a car is a complex machine that if not modified properly, will create a safety hazard and most likely also damage the machine.
So why should you consider a computer noobie to be any different. Why, magically, should a computer noobie be able to perform a performance enhancing modification upon their computer, without having to obtain the necessary knowledge to do so, and without calling a computer mechanic to do it for them, when an auto repair noobie would obviously study up on auto repair first before attempting a performance enhancing modification to their car themselves, or would simply call an auto mechanic.
That is the tiny, but subtle point, missed by most noobies when they start complaining "but no one will help me with my problem". A computer is a complex machine, just as a car is a complex machine. It should be expected that you should obtain some basic working knowledge first before attempting modifications to either machine. There's nothing magical about a computer that makes the need for the necessary background knowledge disappear, just because it's a non-mechanical bit of silicon with electrons scurrying around inside causing work to be performed and waste heat to be generated.
How about it Kim, care to pos
Ignoring the noob comments, they've been dealt with already.
When you say "there was only one swap hard drive partition" do you actually mean a "swap partition" instead of a "swap file"?
If the answer to the question above is "yes, a swap partition, not a swap file", then answer me this: If you already knew about swap partitions, and had been using a swap partition, why did you go and format your 8 ramdisks as e2fs file systems, create empty files for swap files, and go the route of swap files inside an e2fs filesystem residing on a ram disk? What was your reasoning for choosing swap files over the solution presented by the other anon. of simply directly using the ram disks as "swap partitions"?
Now I await an answer that, sadly, I believe will never arrive.
I'm waiting too but given she
I'm waiting too but given she ignored (detailed) points earlier i'm not holding my breath. I haven't seen any comments from her at 25 august anymore. Perhaps she gave up or is rewriting a balanced article instead. It's up to the (newbie) readers now and i'm confident we made a good achievement by debunking this pseudo-scientific nonsense. Kudos!
I'm waiting too but given she
Sadly, if you'll check the newer articles, she hasn't given up (as you correctly predicted). She's still there, and still up to her same old tricks. When she simply does not ignore a valid point, she argues back totally off the wall tangents that have nothing to do with the discussion at hand, trying to confuse the issue enough to make people forget what they were trying to convince her of.
And of course, she is still pushing her snake oil as a wonderful idea.
Hmmm...
Its from the main page now... :) if we just ignore it, it wont be in the "active forum topics" either unless Kim posts something again (repeating what she already said but slightly reworded). Also, its one of the least "top nodes". I don't think we got anything new to add. So if we just ignore it...
Keep it Simple
It is great that scripts can be written is much shorter form.
To me it is better to make the code as easily understandable as possible. This script you gave is for one amount of ramdisks and is more difficult to follow. To me, it is better to leave it simple and less elegant so more desktop users can use it, not just the initiated.
After all, this is supposed to be software that is free as in freedom. So that people can help themselves.
I have seen many articles in the technical magazines. In general, the more calculus equations they contain the less useful they are to most people. But they do serve to make their authors seem very knowledgeable on the subject, and it keeps the number of questions down.
Keep it Simple
Typically, to a point, shorter often equals easier to understand.
Then please explain how your script is more understandable than the very simple for loop posted by the fellow anon. Your script is 63 lines, and highly repetitive, the anon.'s script is 9 lines (including the blank line) and is non-repetitive. In the case of your 63 line script, someone adopting it for their own system could easily make a tiny typo in one line of the 63 lines, and when things don't all work properly be wondering what is wrong, because the extra redundancy obscures the typo. With the 9 line script, a typo is easy to see, because there is no obscuring redundancy.
Please also explain how your own 63 line script is not also for one amount of ramdisks. Your 63 line script creates exactly 8 ram disks, numbered 2 through 9, no more, no less. The anon.'s script actually produces 9 ram disks, numbered 2 through 10, no more, no less. How is your script, which produces a fixed number of ram disks (8 ram disks), not for one amount of ramdisks (8 ramdisks) when the anon.'s script is for one amount of ramdisks (9 ramdisks)? Yet again, your logic simply fails to add up.
Also, note that for your script, if at some point you buy an additional 512MB of ram, and want to make four more ram disks from part of it (who knows, you might, you like this idea so well) you have a lot of editing to do to modify the script. With your 63 line script, you have to add four new lines six times over (in each of your six sections) for a total of 24 new lines, any one of which if you are not careful you could accidentally make a typo upon. With the anon.'s script, to add four more ram disks requires changing one line, "END_RAMDEV=10" to "END_RAMDEV=14". That's it, suddenly the script creates four more ramdisks than it did before. All from a one line change.
Actually, anyone with enough savy to be able to understand the premise of your article, and to be able to even undertake making such a change as yours to their system, even if they were uninitiated, should have enough reasoning ability about them to be able to read through the 9 line script and reason out what operation it is likely performing. In any case, three additional comment lines could be added to the anon.'s script to clearly indicate to the uninitiated what they should change to make a modification to the script. In the case of your script, you'd need a whole lot more than three comment lines to clearly and cleanly indicate to someone who was uninitiated how to modify it to fit their situation.
And since I know you won't be able to reason out the content of the comment lines yourself, here they are in context for you:
Except that there's not a bit of calculus in the anon.'s script. It's a simple shell for loop. Anyone who's ever taken even a beginner programming class should have seen a "for" loop somewhere within the first 1/4 of the class period.
This is yet another example of your mixing apples and oranges to attempt to make your point. There's nothing at all complex about the anon.'s script, in fact it's quite a basic simple script, something that most of us anon's here dash off on the command line on the fly to make the computer do something repetitive that we want it to do for us. Someone who is unable to reason out how the for loop works very likely should not be attempting your script either, because they run a very huge chance of messing up something about their system, rendering it unusable.
KISS is subjective.
Adding a comment explaining what is happening to the less technical inclined is a Good Thing in complex scripts or source code. Although this was quite simple therefore a comment wasn't needed IMO. It appears it was for Kim and she's entitled to that opinion.
Morever, i argue just because one doesn't understand (what is perceived as) chaos is not an indication of quality of that (perceived) chaos. It doesn't even define chaos as chaos. For example some people will never be able to understand what we'd define as basic maths (algebra for example) and would define it as chaos however that doesn't mean algebra is of bad quality and should be replaced.
Also, just because one shows to be unwilling to grok or learn about a particular mechanic does not say anything about the complexity, simplicity or quality of that mechanic.
In this particular case what the anonymous author of the script did was from my point of view simplicity because i understood it. It is true that what one perceives as logic or simplicity another sees as chaos or complex. In the worst case, this is just an alternative to the script Kim provided. IMO, as i said, it is defined as (more) elegant. I find it sad when one who's interested in how the Linux kernel works as Kim appears to be doesn't want to understand a script like this because loops are quite common in shell scripts thus the knowledge is in general useful while it is also useful in programming.
Oh... My... God...
There is nothing remotely complicated about that shell script! It is, in fact, much easier to understand than the long form, since it is far shorter and dispenses with all the wasteful fussing around with dd and ext2. Also, the shorter script is far less bug-prone, as the numerous corrections to the long form version have amply demonstrated.
It's more flexible too. It is not "for one amount of ramdisks", that's what the parameters at the beginning are for! If you wish to use /dev/ram23 through /dev/ram96 you simply have to change the two variables at the beginning, not copy and manually edit 500 lines!
Your enthusiasm is admirable, but I humbly suggest that you study "man bash" for a couple minutes before you continue your open source adventures. And, while you're at it, find a good computer science text- this is hardly the first conceptual deficiency you've demonstrated (e.g., confusion about executable code vs. volatile data, purpose of buffers, purpose of swap, etc., etc.).
Anyway, for extra credit, here's an even simpler script that simply mounts all available ram disks as swap:
[WARNING: FOR PEDAGOGICAL PURPOSES ONLY. DO NOT TRY THIS AT HOME. SWAP ON RAMDISK IS AN INSANE THING TO DO!!]
#!/bin/sh
for ramdisk in /dev/ram[0-9]*
do
mkswap $ramdisk
swapon $ramdisk
done
Here's a quote from a Linuxworld Article
This is from an article entitled "Does Linux have an image problem?"
by the Linuxworld staff
on this link:
http://www.linuxworld.com.au/index.php/id;1750394049;fp;4;fpid;4
'"At the CS dept of the school I work at," wrote a contributor to a well-known message board earlier this week, "many students associate Linux with sweaty arrogant zealots and loudmouthed dorks and thus don't use it when they can get by without using it (certain courses require it)."'
Not my words at all, but . . .
From where I sit...
I see only one misguided zealot, and a lot of more knowledgeable folks earnestly trying to correct her before she manages to mislead anyone else. (Some of the correcters are growing a bit frustrated, to be sure.)
From where I sit...
Frustrated, yes, but trying to correct her in any case. But she simply steadfastly refuses to see any logic at all. I belive she is seeing the logic (well, the alternative is too daming) but is simply so attached to her idea that she simply can't let it go.
Oh, btw, (other anonymous as
Oh, btw, (other anonymous as the one here above) do you think swapRAM is "Keep It Simple" compared to RAM? Is it your opinion your article is a valuable contribution for a Linux noob? Pot, meet kettle. Although i don't see a kettle as you do, but...
Oh, btw, (other anonymous as
A very valid point, I concur. I missed making that point to her "keep is simple" posting. But yes, using her own words "keep is simple", she should also explain how her swapram system is in fact simpler than simply using all 1.5G of her newly expanded RAM as plain RAM, and then turning off her swap partition if she does not like the swapout the kernel does to help her jobs execute faster.
Actually...
I wondered why she didn't just use the ramdisks as well, so I gave it a whirl under my 2.6 kernel. Doing a mkswap directly to a ramdisk doesn't work, because the size of a ramdisk is more or less zero unless it has data in it. Mkswap fails because it won't make a zero sized swaps.
dding from /dev/zero does not appear to help either. Try this (not beause it has anything to do with this discussion, but becuase it is instructive about ramdisks):
Putting in a filesystem works, so she wasn't doing the filesystem for no reason. I suspect copying in from /dev/urandom rather than /dev/zero would have enabled use of the ramdisk as swap directly.
No, I don't agree with the whole swapram business, but let's not dump on her for everything she says or does. Yes, the script she wrote wasn't very pretty, but this one (at least on 2.6) doesn't work at all.
Also, Kim, why don't you just use 2.6 with Con's patches or something. You have stated that you don't think it's completely stable, but there are many many strong comments from the core kernel team and Linus himself that say that it is.
Actually...
Ok, you make a valid point, if you can't directly mkswap on a ramdisk because it has not allocated any memory yet, then that's why she went the file system route.
However, I did notice one typo in your script. It may be editing, but if it's not, it's quite significant:
You dd'ed into /dev/ram, but hexedit'ed /dev/ram5. The destination of your dd didn't match the source of your hexedit. Give it another whirl with of=/dev/ram5 and see if it makes a difference.
Typo city
Yep, that's a typo. Sorry about that.
Typo city
But, does correcting the typo make a difference in the results?
Piggin likes swap, and in a ramdisk it won't slow things down
A quote from Nick Piggin:
From: Nick Piggin [email blocked]
Subject: Re: why swap at all?
Date: Wed, 26 May 2004 19:48:10 +1000
John Bradford wrote:
> Quote from Nick Piggin [email blocked]:
>
>>Even for systems that don't *need* the extra memory space, swap can
>>actually provide performance improvements by allowing unused memory
>>to be replaced with often-used memory.
>
>
> That's true, but it's not a magical property of swap space - extra physical
> RAM would do more or less the same thing.
>
Well it is a magical property of swap space, because extra RAM
doesn't allow you to replace unused memory with often used memory.
The theory holds true no matter how much RAM you have. Swap can
improve performance. It can be trivially demonstrated.
***************************************************************
There was probably some resistance to this because people don't like waiting for swapping-back-in. But if you use a ram disk for swap, you can have both some swap and no swap-back-in waiting.
Yes, and? At best this proofs
Yes, and? At best this proofs there are now 2 people in this world believing what you're saying. If it can be trivially demonstrated, please do. I, for one, am looking forward to it. I'm looking forward to the scientific statistics and i'm even looking more forward to the actual numbers between any scientific correlation of several conditions of $swap_size, several conditions of $ram_size and $performance. Please, do. Currently, you've provided no framework to conclude anything on even though someone appears to agree with your logic.
Nothing to be upset about here
"Well it is a magical property of swap space, because extra RAM
doesn't allow you to replace unused memory with often used memory.
"The theory holds true no matter how much RAM you have. Swap can
improve performance. It can be trivially demonstrated."
The author of this would be just as appalled by swap-in-ram as the rest of us (the quote is Nick Piggin in a LKML excerpt posted to kerneltrap some time ago).
The reason that swap improves performance is that it allows the kernel to temporarily evict some unused data in order to make more memory available to speed up active jobs ("often used memory"). Moving unused data to a different region of memory does nothing of the sort!
Nothing to be upset about here
This is the subtle, but extremely important point, related to the very definition of what swap is for, that our Kim seems to continue to fail to understand, or at this point, flaty refuses to understand. Swap exists to free up memory (RAM) for other uses by moving less used bits of memory (RAM) out of memory (RAM) to somewhere else.
Nothing to be upset about here
"Moving unused data to a different region of memory does nothing of the sort!"
I.e., shuffling the disused data to a ramdisk, in case that wasn't clear...
Right, i got confused because
Right, i got confused because the quoted text said: "The theory holds true no matter how much RAM you have." She got me there. However it doesn't matter since the unbiased circumstance is either RAM or swapRAM (same amount) which is the same as you said, but written in my own words.
Yes, and? At best this proofs
As am I. I'm the anon. that's written several of the longer postings, including the lengthy one with links to "the scientific method" texts available online. I would love to see Kim produce an unbiased, accurate, careful, repeatable (this is a critical aspect) set of test conditions (based upon what is written in the links to "the scientific method" that show her idea is as incredible as she herself belives it is. Sadly, she can not do so, not because she's incapable of doing so, but because the numbers simply won't pan out, and because she's so wedded to her belief that it's better, that she can't see the forest for the trees.
However, this anon. also predicts that Kim will simply ignore the request, as she so often does when pressed for hard facts, or will in fact respond, but by hand waving and trying to divert attention (please ignore the man behind the curtain).
Also (same author as above) i
Also (same author as above) i'd like to see a link to the actual source. Basic etiquette in discussions, research: When one quotes, one state the source and adds a reference. I'd like to see this to understand the context, conditions, because i don't trust you and to find out more about the background of the character "Nick Piggin" of whom i never heard until now.
Like people are telling me, google him.
LKML: Nick Piggin: Re: why swap at all?
Date, Wed, 26 May 2004 19:48:10 +1000. From, Nick Piggin <>. Subject, Re: why swap at all? John Bradford wrote: > Quote from Nick Piggin ...
lkml.org/lkml/2004/5/26/101 - 11k - Cached - Similar pages
LWN: Patch: mm improvements 3/5
... Patch: mm improvements 3/5. From: Nick Piggin . To: Nick Piggin . Subject: [PATCH 3/5] mm improvements. ...
lwn.net/Articles/69551/ - 12k - Cached - Similar pages
Hmmm...
An eye for an eye just because it appears i agree with people you disagree with of which some are telling you to Google. Hmmm. Dangerous grounds in a dangerous discussion.
Oh well, here is a link http://lkml.org/lkml/2004/5/26/101
Other mirrors to be found with Google, yes. Thank you.
I would like to encourage the scripting improvement
I would certainly like to encourage the improvement of the script I gave in the article, especially toward a script that does everything and is interactive. That would be great, and require no special knowledge on the part of the person using it. Hopefully very easy to use and errorless.
Maybe someone has already provided it. I had no time today to check what has been posted lately, and my work won't permit much time tomorrow either. Anyway, I haven't read the new posts yet.
There could be a script for just trying swapram, another to make it permanent if it did what was desired. It could ask what percentage of RAM is desired to be used as swap, if it is to be permanent, if it is being run this time to change swapram parameters, turn it off, leave it off, etc.
This would require a way to see what the current default ramdisk size is, then a modification of the grub.conf or lilo.conf (or other boot loader) to include the new ramdisk_size=xxx command. Then a reboot, and resumption of the script, either automatically or manually. Then it would just need the swapram setup steps, which certainly can be refined.
From the outside, everything would be provided for the user except that the user would have to make a few choices (which could be a problem, I know). The script would be run, and ask if the changes should be 'permanent', find the default ramdisk size, or just set it based on the size of ramdisk requested. Then set up the ramdisk(s) as swap, then turn on the ramdisks, and give the option to turn off the hard disk swap and set relative swap priorities. It would also be good if it checks and reports the current amount of RAM, and suggests the relative sizes or RAM and swapram to use. Maybe there could be a script written that monitors the use of RAM and swap over a couple weeks before swapram might be tried, to see what the usage patterns are, and to advise as to the amount of swap needed.
Now that would be a large improvement over my simple script.
Desktop Users *Hate* to wait for a window to appear
This email is in the "Is Swap Necessary?" article at:
kerneltrap.org/node/view/3202
"From: Nick Piggin [email blocked]
Subject: Re: why swap at all?
Date: Wed, 26 May 2004 18:44:58 +1000
Buddy Lumpkin wrote:
> No. I am not making any assertions whatsoever. I am just calling out that
> systems that run happily from physical memory and are not in need of swap
> should never sacrifice an ounce of performance for even drastic improvements
> to swap performance. Swap is a band-aid for saving money on memory and a few
> years ago, it allowed you to save a substantial amount of money.
>
Hi Buddy,
Even for systems that don't *need* the extra memory space, swap can
actually provide performance improvements by allowing unused memory
to be replaced with often-used memory.
For example, I have 57MB swapped right now. It allows me to instantly
grep the kernel tree. If I turned swap off, each grep would probably
take 30 seconds.
The VM doesn't always get it right, and to make matters worse, desktop
users don't appreciate their long running jobs finishing earlier, but
*hate* having to wait a few seconds for a window to appear if it hasn't been used for 24 hours."
Probably one of the reasons that desktop users apparently "*hate* having to wait a few seconds for a window to appear if it hasn't been used in 24 hours" is that most have come from a Microsoft background. They probably have to use Microsoft at work, and this experience of waiting (depending on hardware speed) a few or more than a few seconds is going to look like a downgrade from their experience at work. You go to work even after the weekend, log in, and any applications you left running are there almost instantly. With Linux (mostly with the 2.4 kernel), if you come back to your computer after even a few hours, then you do have to wait for some of the windows to appear. So that is probably what is disliked. I know that is what I disliked.
So I did something about it (swapram). And now my computer runs smoothly, Linux 2.4 feels great. I thought someone else might like to use this, and I bet some are using it. But you can be sure they are going to get hit with a feeding frenzy by the thought police here who are protecting "noobs" from something that would actually help.
Getting rid of that latency (which I don't notice much on a 2.6 kernel, except with many many programs up at the same time) will help the adoption of Linux.
Kim
This is mindboggling ...
> Even for systems that don't *need* the extra memory space, swap can
> actually provide performance improvements by allowing unused memory
> to be replaced with often-used memory.
True.
> For example, I have 57MB swapped right now. It allows me to
> instantly grep the kernel tree. If I turned swap off, each grep
> would probably take 30 seconds.
If you have 57MB swapped on disk this is true. Swapping freed up some RAM that can be used as disk cache/readahead which speeds up your grepping
If you have 57MB swapped in memory this isn't true. Swapping didn't free any memory. Worse, by removing RAM you reduced the kernel's ability to do buffer/readahead, and your grep is slower now.
> The VM doesn't always get it right, and to make matters worse,
> desktop users don't appreciate their long running jobs finishing
> earlier, but *hate* having to wait a few seconds for a window to
> appear if it hasn't been used for 24 hours."
True. If you have swap on disk, the VM might decide to swap out programs (in order to free RAM so it can buffer parts of the disk and speed up your grepping for instance).
If you don't like this behaviour, simply turn swap off. It won't hurt. Really.
Please read this again. Carefully this time. Try to understand what I'm saying. If you still believe turning part of your available RAM into a swap-partition is a good idea, please let me know why.
This is mindboggling ...
This anon predicts that you won't ever learn why. Instead, this anon predicts that you'll either be ignored (typical tactic), some unrelated aspect of your posting will be quoted and responded to (almost as typical a tactic as ignoring), or you'll simply get a repeat of what she's already said 50 times over. Apparently she belongs to the camp of: "if I say the same thing often enough, people will begin to belive it".
Fallacy
"if I say the same thing often enough, people will begin to belive it".
Which is the fallacy "argumentum ad nauseam"
http://en.wikipedia.org/wiki/Argumentum_ad_nauseam
http://www.infidels.org/news/atheism/logic.html#nauseam
Fallacy
While we are at it, she is also guilty of this one too:
Argumentum ad novitatem
Agreed, but your link doesn't
Agreed, but your link doesn't work.
Here's 2 references which are working
http://en.wikipedia.org/wiki/Appeal_to_novelty
http://www.infidels.org/news/atheism/logic.html#novitatem
Sigh
After all the time and energy invested in your unproven zealotry, you still are unable to comprehend this doesn't apply in 1,5 GB RAM versus 0,5 GB RAM and 1 GB swapRAM. You don't COMPARE to swap because you use swapRAM. You have to compare to RAM, not to diskswap.
Let me add that almost nobody
Let me add that almost nobody (a very small number of people, perhaps) does what you do. When people talk about swap, they mean diskswap not swapram. Because of this, almost no logic or discussion on diskswap & ram applies to THIS discussion which is based on ram and swapram.
(What you quote, for example, doesn't apply here. It is a fallacy. Ie. wrong compare made.)
Sigh
If you go back and look through all the comments attached to this article, you'll find one where I also pointed out to her that she was comparing apples to oranges and declaring a conclusion. Such application (or misapplication) of logic to the problem will not faze her. She will either ignore it, repost a correction to her scripts, or argue back a totally unrelated point in an attempt to divert attention from the sharp point made. But she won't admit that she made any mistakes, because in her mind, she's an infallible expert on the linux VM and swap.
Swapping for caching is an optimization tradeoff
I'm sure that about all I say here, is already said in this forum but I'd like to crystallize few things. I'm also talking things more in general than just 2.4-specific, sorry about that.
First of all, physical RAM is used for 2 main things:
1) program resources (code, data, stacks, i/o buffers, etc). These resources can be divided to 2 classes:
a) swappable (all typical application code/data/stack, etc)
b) non-swappable (some or all kernel portitions, dma-areas, etc)
2) cache-like resources (e.g. file cache, but other uses exist also)
Cache-like resources can be also divided to 2 classes:
a) discardable (eg. disk read-cache)
b) write-back (eg. disk write-cache)
Basically, when there is enough RAM in your system to run all class 1 stuff, you don't need swap at all. All free memory can then be used for class 2 stuff.
However, consider for example, that you would have 256MB memory, 192MB of application load (of which active part is 100MB), and you operate on 100MB worth of files. If you know these, you would probable swap out 36MB of inactive application data to make room for 100MB of cache.
Swapping to make room for caching is an optimization problem: swapping for throughput suggests bigger caches, and swapping for desktop responsiviness suggests smaller caches. Only if your active set in class 2 data is smaller than available free mem, you never need to even consider swapping.
The problem with current VMs (especially 2.4) is that they make often very bad choices. With one big read of file (try dd if=big_file of=/dev/null bs=16384) you end up a lot of swapping, because the 2.4 VM wants to cache. And your desktop is sure to have bad response times first time after that read. If only I could tell the VM not to swap here...
From VM perspective, when application makes file reads, it is hard to say whether they should be cached or not. This actually requires predicting the future use, and some VMs do that better than others. (This is somewhat comparable to the problem of processor caching)
For better desktop use the VM should be more conservative, i.e. not too eager to swap to make room for caches. Using part of RAM as swap hack can actually do this, as some minimum amount of the RAM is forced for class 1 (the memory swap part) and less can be used for class 2. But nonetheless, the hack is an ugly one, and the only reason why it improves things is that it occludes more fundamental issues in the VM.
]S[
Simpler solution
Turn swapping off. Applications won't be swapped out.
Advantage: ALL other memory can be used as buffers. In your scenario that isn't neccessarily so. Example: 1GB RAM, 512MB SwapRAM, 750MB Application data. This will result in about 400MB Application data in normal RAM, 112MB buffers, 350MB of application data in swapRAM and *gasp* 162MB UNUSED RAM. Without swap you'd have 750MB Application data and 250MB buffers. Much better, much simpler. Win-win.
Simpler solution
Sigh, you are about to enter the world of Kim. This is a world where logic does not exist, a world where Kim is right, always right, right no matter what, and can't be told otherwise.
We've told her exactly this before. But she's so steadfastly attached to her idea that she's simply blind to any other superior solutions and will faithfully ignore and/or argue that her method is better. If you check the pages upon pages of comments attached to this article, you'll see what I mean. She won't provide any hard data to back up her arguments that her idea is better than simply surning off swapping, and she will handwave away and/or ignore anything anyone posts to the contrary.
In any case, you are totally correct, the simple solution to her perceived problem is, buy more RAM (she did that), and turn off swap.
Thanks to the few brave souls that say something positive
Thanks to the few brave souls that have said they tried this swap-in-a-ram-disk. And then to report good results! That takes real courage.
That takes courage on this discussion group, where there are so many masters of logic and scientific method. Some are masters to such a degree they will keep themselves from good solutions to their own problems by being so bound by conventional wisdom. Many inventions occur when someone notices some part of conventional wisdom is incorrect, and figures out how to do something about it. Then there is a new invention and many people will be against it because it is against conventional wisdom. That's life and how we all react to some new things.
If you can't solve a problem using conventional wisdom, try unconventional wisdom. Sometimes it works, sometimes it doesn't, but after conventional wisdom has come up with no solution, it is time for trying new things which will be, by definition, unconventional.
Remember that people once said, "If God had meant man to fly, He would have given him wings"? Well, here it is about this: If God had intended men to use a ramdisk as swap, He would have made the second RAM slower so it would have been acceptable to the masters of logic and scientific method, and people could use it without fear of ridicule.
I had good results with it also also.
It is not easy to go against conventional wisdom, but every once in a while, when you do, especially if you know that it works, even under just some conditions, you get a good solution that nobody would have thought of. Well, maybe they did think of it but they rejected it as a possible solution, or would have just known it wasn't right, based on the conventional wisdom.
I don't mean everyone here is that way. Many opposing views are reasonable. Some Anonymi are reasonable.
It is interesting to me how sensitive an Anonymous can be about being called Anonymous. Some have called that name calling.
Yes, swapram is a workaround, which here they call a hack, an ugly hack. Wow, this makes me a kernel hacker! I never thought of it that way. (I can hardly wait for the replies to that one.)
Well, I fix a lot of things in ways considered ugly. Most times those needing their product fixed are very happy to have the problem solved. The first fix looks ugly. It is usually quick and dirty so you can get the product out the door. Then it gets refined and better looking in later revisions. 2.6.0 was a little ugly? That is the development process.
There are so many posts, and I have gotten behind on reading them. Maybe I will get caught up some over the weekend.
Thanks again, and don't be surprised if there are many people vehemently against it. And arguing with every point in this post too. Some of them are just having fun.
Kim