Slashdot Mirror
Tuning Linux VM swapping
Lank writes "Kernel developers started discussing the pros and cons of swapping to disk on the Linux Kernel mailing list. KernelTrap has coverage of the story on their homepage. Andrew Morton comments, 'My point is that decreasing the tendency of the kernel to swap stuff out is wrong. You really don't want hundreds of megabytes of BloatyApp's untouched memory floating about in the machine. Get it out on the disk, use the memory for something useful.' Personally, I just try to keep my memory usage below the physical memory in my machine, but I guess that's not always possible..."
Ah yes. It's all the fault of bloaty apps. Apps like database daemons and high-traffic httpd daemons. We've turned swapping off on our servers because we were sick of seeing almost a GB of cache/buffer memory, while it was swapping 500MB of shit to disk. Want a bloaty app? How about the linux Kernel? I love the thing, but Jesus Tapdancing Christ it would rather swap our starting DB process to disk, than free up the fucking buffers and cache. Is there something wrong with wanting it to give precedence to not swapping?
Read: Rabbit Rue - Free serial nove
With read-only & demand code-page loading and copy-on-write even bloatware really doesn't eat memory. And bloatware has to be frequently restarted to recover the memory it leaks.
Sure, there are some jobs that needs swap -- lots of seldom used memory pages.
But not mine. I prefer to save myself the complexity and performance headaches.
Yeah there is nothing I love more than coming to an idle X console session on box I haven't touched in a while and watching it grind itself into oblivion because everything has been paged out.
At what point does VM stop meaning Virtual Machine and start meaning Virtual Memory.
Or is it just the Virtual "M"?
Disk corruption is handled seperately. If you don't trust your drive controller, then you should spend some time fixing up the disk writing susbsytem. Disk writes should be guaranteed if they say they're succesful, except in the case of a power failure. At that point, swap integrity doesn't matter anyway. :)
/proc/sys/vm/swappiness
Without a swap file, the kernel has no place to stick memory segments that are rarely used. They stay in resident memory la-la land until the process is terminated. Those segments add up over time and erode the memory available to the page cache.
Page caches are wonderful. When you load an application (like Firefox), you're not just getting the web browser. You're firing up a large chain of shared objects/DLLs that support the widgets, I/O, and components of the application. All of these components must be read into memory anyhow for program operation, so the kernel tends to just leave it in there for future use (the page cache).
When you shutdown Firefox, you're also releasing the necessity of those libraries (provided nothing else is using them). Those libraries also remove themselves from memory. If you load another application (like Thunderbird) that uses the same type of libraries, the kernel will not have to go to disk in order to fetch those libraries. It will instead opt for the page cache contents.
Turning off the swap file in the historic era of VM infancy was the best way to remove the hard drive bottleneck from system. The operating systems of yester-year did not have good page cache schemes that took advantage of all that unused memory. It is a little different now.
Applications are so modularized that they are broken up into a billions of smaller libraries so that code can be shared. This increases memory efficiency by keeping a shared library resident for multiple processes. These libraries are frequently accessed, more often than many people realized. Getting THOSE into memory is better than making sure my 500+ Linux applications stay resident.Notice that on a web server with 1GB of RAM the Linux kernel is still putting things out to swap. These processes that stay asleep for long periods of time do not need to waste the memory that page cache is currently using (892309504 bytes or 753.7MB). What would be stored in that 753.7MB of memory? The database that drives the website (instead of having to seek the disk). The entire web page hierarchy used to display pages on the web site. All the scripts that are used to display dynamic content on the web site (etc. etc.)
Now, if we subtracted from the page cache the amount of memory that was stored in the swap file, we would have over 200MB less that we could keep cached in memory. That could be an entire database that the kernel would then waste needless CPU cycles to fetch from disk.
The only advantage to turning off a swap file on these modern machines would be for a machine that runs only a select few applications, and not having a lot of processes in the background doing things.
Ayup
True, but in most real applications the latency of the disk is the real cost of using the system -- you don't tend to do sustained transfers from swap to CPU. Most memory accesses use a small amount from a single page and then skip to using another. Modern programs tend to have very bad locality of reference.
That's what FreeBSD's been doing for years, and for a long time kernel hackers spoke in awe of the much-vaunted FreeBSD VMM. Now that Linux has implemented a similar strategy, everyone's freaking out like it's some new ego trip that noone's ever tried before.
The "new" system is what other OSes have been doing for years, and it makes sense. Sometimes it's better to learn why such big changes are made than to gripe on Slashdot that things aren't the way they used to be.
Dewey, what part of this looks like authorities should be involved?
Whatever swapping scheme is used in Windows, I do not know, and I don't care what it's called either.
What I can't despice, is the fact that I got >300MB free physical memory, and 20MB of the kernel is still swapped. Result? Do this, do that (any minor thing) and you have to wait for it to swap in.
In the end, I have never ever seen a Windows-system without a partially swapped kernel, even with tons of free RAM available.
This is just plain stupid, or is there some sort of "smart" explanation for this?
I, for once, would hate having to turn off virtual memory, just to have the system kernel loaded at all times.... And GOD BE DAMNED if Linux takes the stame stupid design-decision.
Not Buzzword 2.0 compliant. Please speak english.
So way you want to do is:
So if the guy goes to leaving a big make running, it gradually pushed the big apps out while it runs. But if the big make completes, the apps start crawling slowly back in. If it hasn't finished when he comes back from lunch, he probably wants it to carry on running the make: since the CPU is at 100% load, he is probably not surprised it is sluggish.
Consciousness is an illusion caused by an excess of self consciousness.
http://00f.net/item/14/
describe why swapping is _good_.
{{.sig}}
One of the best methods I've heard of for swapping stuff out is to be aggressive about it but not complete the process; that is, the VM manager can write hundreds of pages to disk but not remove them from memory. Then if another application suddenly needs a lot of memory, it can very quickly free up the memory without the delay imposed by swapping it out. Or if the "swapped out" application needs to use its memory, the pages on disk can be quickly marked as invalid and pages in memory used instead.
Yeah there is nothing I love more than coming to an idle X console session on box I haven't touched in a while and watching it grind itself into oblivion because everything has been paged out.
What's wrong with that? The machine shouldn't sit and be ready for every possibility. If you've not logged in in X hours, it shouldn't expect you to suddenly log in. It grinds for a minute or so, and then it's fast again cos it's got what you want to use in RAM. Which is the whole point of swap, stuff you're not using gets paged out.
Linux does (can) do this: see tmpfs.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
- The process needs to read the page - no problem, one copy is in RAM just read it, and keep both copies.
- The process needs to write the page - no problem, you can modify the copy in RAM and discard the copy on disk. Notice that discarding the copy on disk doesn't require any disk access, as the list of swap allocations will typically be in RAM (it is much smaller than the swapspace).
- You actually need memory - no problem, discard a not recently used RAM page, you still have a copy on disk.
The only problem is, that you need to make the page readonly, so you can trap the write and discard the on disk copy. In other words don't do this for pages that are frequently changed. But usually you don't have many pages that are frequently changed, and you certainly don't want to swap out those you have. And should you occationally happen to swap out one, it is not really a major problem. It will cost you a pagefault, but no disk I/O. And a pagefault is compared to a disk I/O. A system that behaves like I have described here would use a lot more space than Linux typically does, but still it should be faster. I wonder why this isn't done more often, it is not like the idea hasn't been known for years.Another problem that many have noticed, and that isn't easy to deal with, is heavy diskaccess causing the cache to grow and stuff getting swapped out. Yes even some Linux versions suffer from this problem. A Red Hat 9 system I had running for months was really slow in the morning, because all the programs had been swapped out while cron jobs where running during the night. But you never know when it is a good idea to swap the stuff out and when it is not. When the disk access is going on, the process page might not have been used for hours. But still you might want it to be kept in RAM. File pages that have been accessed just once shouldn't be kept in cache for long time. But of course you shouldn't remove them unless the memory was needed for something else. Removing the pages too early is also bad, because you wouldn't notice, that this was really a page that was going to be accessed frequently. Some people are fanatic, and don't want process pages to ever get swapped out to make room for cache. That isn't a good idea either. You can really have process pages that may not be needed even once, do you want such a page to be kept in ram for months just in case? And notice how disabling swap is not going to solve the problem. You still have to think about memory mapped files, that in many ways must be treated like anonymous mappings.
Do you care about the security of your wireless mouse?
The thig I hate about 2000 is that it seems to hold on to this disk cache RAM for dear life. Eventually, if you hibernate/unhibernate, or just don't turn off the computer, you swap for everything. It's a real pain in my assass well. I've disabled virtual memory on my windows machine at home (at work, I run too much to do so), just because it's not really needed and makes it much faster.
-no broken link
I've seen a number of posts echoing this point, overlooking one of the key reasons for swapping. It's not just because you're out of memeory for applications, it's because sometimes there are better things to be doing with your memory. Mainstream operating systems use otherwise unused memory to cache disk access, dramatically speading things up. If you've got an process that hasn't been run for a a while it may actually be more efficient to swap it to disk. This frees up memory to cache data that may be being hit quite frequently. inetd hasn't been needed for a while? Swap it out so that your disk cache is larger, benefitting your heavily used web server.
To be fair, when to make that trade off is very tricky and will never work perfectly 100% of the time. Inevitably you'll occasionally be burned by a bad decision. But there are real benefits. The real question is not how to turn it off, the question is how to improve it and perhaps how to allow users to tune it for their needs.
Search 2010 Gen Con events
I have been using Windows for 12 years (and Linux for 10), and this is the first time I have heard of the obscure registry hacks you just listed. Besides, I thought Windows users argue they should not have to find, learn or research anything at all. It should just work, right?
/proc/sys/vm/swappiness was in the fourth hit from the top. There, that wasn't so hard, was it?
/proc filesystem than wander through the Windows registry any day.
When I just searched for '/proc linux vm swap' in Google,
I can tell you one thing. I would rather poke around the
By the way, if you are not shutting your XP system down often, you must not be rebooting for the security patches, and that can be a problem for everyone. (Yes, I am aware that Microsoft has gone to a monthly release cycle now while simultaneously claiming to release within hours versus the weeks they claim FOSS takes.)
You're right that having duplicate functions in different shared libraries means opposing apps real use of ram is larger than if they both used the same shared library or their shared libraries used a common lower library, but I think you're overlooking another point. Whenever there's a page of a library or a process' code that is going to be swapped out, it can simply be dumped. That means unoften used sections of different shared libraries aren't actually in memory. Also, because the libraries are already on the HD there's no swapout that occurs (though obviously swapin can occur). So the wasted bloat of most libraries matters little. And the often used stuff, which it does take up more ram than if it were unified is still a very miniscule section of ram usage (even at 8MB for qt and 2MB for gtk+ (plus another 1MB for glib and gdk) which cover all gtk+ and qt apps, you're using a amazingly small percentage of any modern system's ram (less than 9% of 128MB); add all the shared libs and you're still not using more than around 32MB which while large provides a massive amount of services for all sorts of apps which would otherwise be much larger). So, unification is good, but it's not nearly the worry that you seem to believe it is.
Eurohacker European paranoia, gun rights, and h
Sorry but this is not a complex equation and I think these guys are getting wrapped up in too many details and missing the big picture.
The harddrive is really, really, really, really fscking slow. In comparison Ram is really really really fast. As a result, you want to interact with the hard drive as little as you possibly can, and interact with ram instead as much as you possibly can (the only thing which beats that is interacting with only the cpu registers and avoiding ram and harddrive altogether).
As is, linux doesn't even begin touching the disk until there is only enough ram left to turn on VM. Now this has a negative impact when that limit is reached because there is overhead turning it on.. this impact is negligable and tweakable since you can wait and see if you hitting the limit, add more memory, see again and reevaluate until you simply aren't swapping. This is a good thing.
One of the worst things windows does is swap constantly. In fact beyond a certain point (read enough ram to run an XP desktop) the system swaps MORE if you have more ram. You boot the system with all uneeded services turned off and no startup processes and all the eyecandy turned off. And you've got 4gb of ram in the system, guess what, it's already using VM.
Maybe VM management itself could be tweaked more, but it certainly shouldn't be used unless it absolutely has to (and if you don't have enough ram and it has to all the time then it's not like you suffer that performance hit more than once).
The only exception to this I've found is a linux desktop running kde or gnome with about 256mb of ram, at that point the numbers seem to work out just about right(or wrong I should say) and the system is constantly turning VM on and off, encountering the performance hit again and again and again, with pretty much every operation you perform.