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..."

Comments

God no...

[0123456]

"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."

I absolutely despise the way that XP swaps out applications in order to make the disk cache larger. I have 1GB of RAM on my machine precisely so I don't have to wait two minutes for it to swap my web browser back in after it's swapped out... yet if I copy a 2GB file from one drive to another, the stupid operating system will swap out all the applications it can just to make the cache larger.

Please, please, don't take Linux down the same braindead route as Microsoft has done for XP. It's utterly insane to swap out my browser so that a 2GB file can be copied two seconds faster when I then have to wait two minutes for the browser to swap back in. Or at least provide some kind of '#define STOP_VM_SWAPPING_STUPIDITY' so that I can disable it.

This reminds me of an old convo I had ...

[DikSeaCup]

I had this conversation with a fellow sysadmin, about the time that RAM was fairly cheap and we had a budget.

She had just procured a new Sun machine with 2 GB of RAM. Mind you, disk space hadn't grown all that significantly and you could still get machines with 9 GB drives.

The original practice was to make swap 2xRAM. So when the student she had putting the machine came to her and said, "What do I make swap?" she responded "Twice the RAM."

He said, "Are you sure? That's like almost half the boot drive."

She thought about it for a second and said, "Oh, yeah. I guess just make it the same as the RAM."

So this begs the questions: What do you make your swap now? When does your rule of thumb change? And remember when you could run a "fast" linux box on a P100 with 64MB of RAM and 128MB of swap?

Re:This reminds me of an old convo I had ...

[13Echo]

I don't normally make my swaps more than 512 MB on my Linux machines. In fact, when I had 1204 MB of RAM on my last machine, it only ever touched the swap once (when I was compiling Mozilla). The machine was so responsive with 1024 MB of RAM, it virtually never needed to use the swap with that much RAM.

Now that I have a newer machine, and RAM prices have increased (had to replace SDRAM with DDR), I only have 512 MB in my home machine. It seems to be nearly as responsive, practically never needing to touch the swap. I've only ever seen it use a few MB of the swapfile. When partitioning my Linux drives, I almost always have more than one drive in the machine. HDA1 normally gets the root partition. HDB1 is normally my swap, at the front 512 MB of the drive, followed by home on HDB2. This system makes everything snappy.

Even on my work machine, which is only a p3 450 with 256 MB of RAM, things operate quite well under Gnome 2. I have two drives in that machine as well, and the swap is on a seperate drive from the root partition. Programs can load from one drive while simultaneously swapping (if necessary) to a second drive. Even with Gnome 2 running, in addition to my browser and several other apps, only a few KB of space is being used on the swap.

I can't see most desktop Linux users needing more than 512 MB of swapfile space, assuming that they have at least 256 MB of RAM. The general rule of thumb, though, is to put the swap partition at the front of the drive for the best performance, in the event that it does need to get used.

I've really been impressed with Linux's memory management, even in the 2.2/2.4 series kernels. I've heard that 2.6 even makes some improvements as well. When I used Windows 2000, on the other hand, it INSISTED on using the swap even with a gig of RAM, even after I tweaked it for the best performance. I even used a RAID0 array, and Linux is still faster and more efficient at managing memory WITHOUT the RAID array. I was surprised that the array wasn't even really needed on Linux for fantastic disk access speeds with my 3 year old 7200 RPM drives.

Of course, the rules will be different for server application. More swap is probably a necessary thing. It's possible, however, that users of Linux (on the desktop) may not even need a swapfile with more than 512 MB of RAM.

Re:This reminds me of an old convo I had ...

[TheLink]

Well, here's my thoughts on swap.

First you should worry about how your O/S does "memory overcommit".

Many O/Ses overcommit mem. How they handle the case when it turns out there really isn't any mem left (including swap) is what you'd want to know. Some O/Ses (and versions of O/S) effectively kill -9 random processes till there's enough RAM to run. Some applications intentionally allocate large amounts of mem and usually don't every use them. So they usually won't work if you have overcommit turned off (and not enough RAM+swap).

If you having tons of swap just to avoid your O/S poor handling of mem overcommit, you may end up in a death spiral of swapping. Running processes page by page off your HDD isn't fun to watch (it's so 50s or was that 60s :) ).

My HDD transfers at max 40-50MB/sec, random seek transfer maybe about 11MB/sec.

At worst case how long does it take to swap out and swap in the largest process you'd ever have, given the speed of the HDD? Can you wait that long? Can the app wait that long? Will the machine be dead for practical purposes?

So if you can wait 20 secs, maybe 512MB is ok, assuming the pig process only uses half or so of your swap (plus whatever physical RAM you have).

But with a small swap, you may run out of mem and hit the memory overcommit scenario.

I'd still keep swap - just so that when my machine runs out of mem starts slowing down, rather than slamming full speed into a hard wall.

Re:Problem

[Trifthen]

No, turning off swap is not disastrous. We've turned it off on our production web server cluster that routinely serves 60Mb sustained traffic. We've turned it off because we have 2GB of ram in these machines, and Linux insisted on preferring buffers and cache over our running applications. Fuck that, we said. With over 1GB Of buffers and cache, we had RAM to spare; bye-bye swap.

Other reasons

[Halo1]

Another reason to gradually and pro-actively swap things out, is that when another program later needs a lot of memory, your system doesn't come to a grinding halt because suddenly a lot of stuff has to be swapped out at once (followed by zeroing all that memory, since you don't want to have one program leaking data to another).

At least, that's the rationale I've read behind OS X's strategy of swapping things out long before all physical memory is used (and of keeping a pool of zeroed memory pages ready to fulfill most requests). Note that this does not require superfluous swap-ins if your reuse strategy is balanced properly, as the fact that something is swapped out doesn't mean that the memory which contained that data will be cleared/reused immediately (i.e., if it's needed again shortly afterwards, that page can be reactivated without having to go to disk).

Under most desktop OS'es, programs can even give some hints to the system regarding their usage of a memory region using e.g. the madvise() system call.

Dumb Swapping is Computer Abuse

[stuffduff]

Programmers have put a lot of time and effort into the VM swapping algorithm; mostly with the intention of being prepared to have a lot of memory ready and waiting for the next thing it will be asked to do. Unfortunately that's not so much of an issue with cheap ram and disk storage and faster and faster front side buses. What we really need is more intelligent swapping, which can only come about when the VM gets a set of API hooks (would make for a great 'shared object') that would enable the system administrator (and maybe someday the end user) to assist an intelligent VM manager to establish priorities and consistently respect those priorities.

Unfortunately the current crop of best guess VM managers end up denying the end user the experience of their computer's peak performance. Coupled with the horrible state of application bloat, modern 'state of the art' hardware and software combine to give us less and less in terms of overall performance. Software developers throw more code at the cpu to add functionality with little or no concern for performance. And hardware manufacturers add more and more 'special instructions' and 'pipelining' which the majority of software is completely unable to access. If anything it's more like a bunch of dysfunctional co-dependents than an industry that is cogent as to what really needs to be going on. If the folks dealing with processors and the application software could take a page from the gamers (look at the high levels of integration between game engines and video cards) for example, and more effort put into consolidating functionality in dlls and shared libraries; we would be amazed at how truly fast these machines could perform.