"P.V.Anthony" <pvantony singnet.com.sg> posted
45F66A32.1050004singnet.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-amd64gentoo.org mailing list
|
