[gentoo-amd64] Re: Is swap need when there is 4g of ram?

[Duncan <1i5t5.duncan@cox.net>]

"P.V.Anthony" <pvantony@singnet.com.sg> posted
45F66A32.1050004@singnet.com.sg, 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