"P.V.Anthony" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Tue, 13 Mar 2007 17:09:06 +0800:
> Is swap really needed when there is a 4g of ram? As VAH says, depends. I ran without swap with a gig of RAM for some time. That was generally enough for me. Only one time did I actually run out of memory, when I tried to scan a larger than really necessary image at too high a resolution and color depth. However... There are several reasons to run swap. It's likely that at least one of the following will apply. Less so with current kernels, but it wasn't that long ago (certainly well into the 2.6 series, maybe 2.6.12-ish?) that the kernel had no direct way to switch memory between different "memory zones". There could be plenty of memory, but memory of a specific type, say in the PCI 32-bit direct DMA zone (up to 4 gig, but note that due to the memory hole for it at just below 4 gig, 4 gigs of actual memory will map a quarter to a half a gig above the 4 gig memory barrier) could be tight, with no way to rearrange things that could otherwise be moved elsewhere into other memory zones, without using the "backing store" of swap. Put simply, swap gave the kernel more flexibility in how it managed memory, a flexibility that could be useful at times. Eventually, the kernel hackers implemented a way to transfer memory between zones without resorting to backing store (aka swap), so this no longer applies to modern kernels per se, but the general idea of flexibility continues to. Disabling swap entirely kills the kernel's ability to memory-map a file on disk without reading it into physical memory. This actually doesn't use the swap space, just maps the file where it is into memory without actually reading it into memory. There are times when this is more efficient than actually reading the whole thing into memory, and disabling swap (as in turning off the virtual memory option before compiling the kernel, I believe it can still do it if the option is on but no swap space is actually allocated, tho I'm not positive on that) kills this flexibility. OK, so those don't apply to a modern kernel in many operational circumstances. It's nice to have the flexibility, but... Still, there are other reasons to keep swap around. There's a balance between cache and swap. With swap turned off, data and memory for all running apps, including those that don't actually run very much (say print services on a system where something's actually printed perhaps once or twice a week on average), /must/ be maintained in real memory. What's used for such applications cannot be used for caching files so they don't actually have to be read off disk once they are read the first time. If you generally never top off memory and cache to the point where the system is throwing away cache to keep memory, and with 4 gig, you may not, unless you use some of the tricks below, it doesn't matter so much, but the minute you start throwing away cache to keep stuff like a seldom used CUPS print system in memory, because you have swap disabled, you begin to slow down your next read of the cached data you just threw away. BTW, with swap enabled, there is a knob you can tweak that sets the kernel's balance between keeping apps vs. keeping cache in memory, when one or the other needs dumped in ordered to make room for something just coming in. /proc/sys/vm/swappiness defaults to a generally reasonable 60, IIRC, but can be set to anything between 0 and 100. Here, I'm running a reasonably fast RAID system with 4-way striped swap, and a 4- spindle RAID-6, effectively making it two-way striped. Since swap is four-way striped while my main system is only two-way striped, swap should be faster than reading stuff back in from the RAID-6, so as part of my boot sequence I "echo 100 > /proc/sys/vm/swappiness". That means the kernel will /always/ prefer keeping cache, dumping the least used applications to swap where necessary. Conversely, people who run a single hard drive with both swap and most of their filesystem on it, who run an slocate updatedb cron job over night and come back to a really sluggish system the next morning because the kernel has swapped all their still loaded firefox tabs and the like out in favor of caching what amounts to the single-shot updatedb data, may wish to set swappiness lower than the default 60, say 20, or even 0, at which point the system would always favor the apps and always dump cache, when it came to that point. However, the BIG payoff of lots of memory (4 gig or so being a sweet spot for this), particularly for Gentoo systems or anyone else doing a lot of "temp" work, compiling or the like, is to setup a large (several gig) tmpfs and do all your compiling and stuff there, only copying the completed files over to the main non-volatile filesystem. On Gentoo, it's particularly easy to use a tmpfs for compiling and the like, by simply setting the appropriate PORTAGE_TMPDIR and similar variables in make.conf. With "only" four gig of memory, however, and with certain packages requiring sizable work areas (OOo is said to require on the order of 4-5 gigs!), trying this without swap risks severe memory shortage situations. I have a full 8 gig memory and a 5 gig tmpfs /tmp (with portage pointed to it) here, and even with 8 gigs memory, if I try emerging several things in parallel, it's not unusual to see active swap as a result. On a four gig system, I'd DEFINITELY want swap backup if I had PORTAGE_TMPDIR and friends pointed at tmpfs (which I might then try at 3 GB max size, tho obviously that wouldn't work if I tried to compile OOo or something nearly as big). It's worth repeating. A tmpfs based PORTAGE_TMPDIR is probably the single best use for 4 gig of memory on a normal Gentoo system, but it's not something I'd recommend anyone try without swap. Therefore, I'd recommend a tmpfs be setup for portage to use, and that swap remain enabled for the system to use in the event it needs it when portage is compiling something big. To try to setup that tmpfs for portage to use /without/ swap enabled... might be OK on an 8 gig system tho I'm not going to try it myself, but is certainly risking trouble and instability on a 4 gig system. Finally, note that the in-kernel hibernate (aka suspend to disk) functionality requires a dedicated swap partition of sufficient size. Suspend to disk is /finally/ working here, and it's a nice feature to have. However, it /does/ require swap space to suspend into. (Note that the swap partition doesn't have to be the full size of RAM. Each of my swap stripes is only 4 gig, making 16 gig of swap available, but suspend will only use one stripe, so 4 gig. I have 8 gig memory but only a 4 gig swap stripe partition to suspend to, but it works fine.) If you are using a non-vanilla kernel with the Suspend2 patch, or something similar, this may or may not apply, as I think it's possible for it to use a non- swap suspend file. However, with the mainline in-kernel suspend, at least last I read, it requires swap. That's actually why I re-enabled swap here, tho it was quite some time before I could actually get suspend to disk to actually work as advertised. I kept swap enabled and would try it every few kernel versions, and it finally started working! So in summary, four reasons to keep swap enabled: 1) Old kernels needed it for memory zone management. (N/A for a decently modern kernel, say 2.6.16 or newer.) 2) Memory mapped file flexibility. 3) tmpfs based PORTAGE_TMPDIR and friends is generally a MUCH more efficient use of several gigs of memory than turning off swap, but until you have I'd say 6 gigs memory minimum, you'll want to keep swap enabled if you do it. 4) Suspend to disk, aka hibernate, uses swap. #3 and possibly #4 are the important ones. OTOH, disabling swap entirely, by turning off that config option in kernel setup before compiling it, DOES significantly simplify kernel code and memory management. This was in fact the reason I had it off back when I had only a gig of memory. I had system stability issues due to unstable memory hardware (cheap memory) at the time, and I figured the less complicated kernel memory management was, the more stable the system was likely to be. I don't know if it made much of a difference, but it definitely wasn't LESS stable. (The memory zone issues did apply back then, but my hardware simply wasn't stable enough for that to be much of an issue.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list
