1 |
"P.V.Anthony" <pvantony@×××××××××××.sg> posted |
2 |
45F66A32.1050004@×××××××××××.sg, excerpted below, on Tue, 13 Mar 2007 |
3 |
17:09:06 +0800: |
4 |
|
5 |
> Is swap really needed when there is a 4g of ram? |
6 |
|
7 |
As VAH says, depends. |
8 |
|
9 |
I ran without swap with a gig of RAM for some time. That was generally |
10 |
enough for me. Only one time did I actually run out of memory, when I |
11 |
tried to scan a larger than really necessary image at too high a |
12 |
resolution and color depth. However... |
13 |
|
14 |
There are several reasons to run swap. It's likely that at least one of |
15 |
the following will apply. |
16 |
|
17 |
Less so with current kernels, but it wasn't that long ago (certainly well |
18 |
into the 2.6 series, maybe 2.6.12-ish?) that the kernel had no direct way |
19 |
to switch memory between different "memory zones". There could be plenty |
20 |
of memory, but memory of a specific type, say in the PCI 32-bit direct |
21 |
DMA zone (up to 4 gig, but note that due to the memory hole for it at |
22 |
just below 4 gig, 4 gigs of actual memory will map a quarter to a half a |
23 |
gig above the 4 gig memory barrier) could be tight, with no way to |
24 |
rearrange things that could otherwise be moved elsewhere into other |
25 |
memory zones, without using the "backing store" of swap. Put simply, |
26 |
swap gave the kernel more flexibility in how it managed memory, a |
27 |
flexibility that could be useful at times. |
28 |
|
29 |
Eventually, the kernel hackers implemented a way to transfer memory |
30 |
between zones without resorting to backing store (aka swap), so this no |
31 |
longer applies to modern kernels per se, but the general idea of |
32 |
flexibility continues to. Disabling swap entirely kills the kernel's |
33 |
ability to memory-map a file on disk without reading it into physical |
34 |
memory. This actually doesn't use the swap space, just maps the file |
35 |
where it is into memory without actually reading it into memory. There |
36 |
are times when this is more efficient than actually reading the whole |
37 |
thing into memory, and disabling swap (as in turning off the virtual |
38 |
memory option before compiling the kernel, I believe it can still do it |
39 |
if the option is on but no swap space is actually allocated, tho I'm not |
40 |
positive on that) kills this flexibility. |
41 |
|
42 |
OK, so those don't apply to a modern kernel in many operational |
43 |
circumstances. It's nice to have the flexibility, but... Still, there |
44 |
are other reasons to keep swap around. |
45 |
|
46 |
There's a balance between cache and swap. With swap turned off, data and |
47 |
memory for all running apps, including those that don't actually run very |
48 |
much (say print services on a system where something's actually printed |
49 |
perhaps once or twice a week on average), /must/ be maintained in real |
50 |
memory. What's used for such applications cannot be used for caching |
51 |
files so they don't actually have to be read off disk once they are read |
52 |
the first time. If you generally never top off memory and cache to the |
53 |
point where the system is throwing away cache to keep memory, and with 4 |
54 |
gig, you may not, unless you use some of the tricks below, it doesn't |
55 |
matter so much, but the minute you start throwing away cache to keep |
56 |
stuff like a seldom used CUPS print system in memory, because you have |
57 |
swap disabled, you begin to slow down your next read of the cached data |
58 |
you just threw away. |
59 |
|
60 |
BTW, with swap enabled, there is a knob you can tweak that sets the |
61 |
kernel's balance between keeping apps vs. keeping cache in memory, when |
62 |
one or the other needs dumped in ordered to make room for something just |
63 |
coming in. /proc/sys/vm/swappiness defaults to a generally reasonable |
64 |
60, IIRC, but can be set to anything between 0 and 100. Here, I'm |
65 |
running a reasonably fast RAID system with 4-way striped swap, and a 4- |
66 |
spindle RAID-6, effectively making it two-way striped. Since swap is |
67 |
four-way striped while my main system is only two-way striped, swap |
68 |
should be faster than reading stuff back in from the RAID-6, so as part |
69 |
of my boot sequence I "echo 100 > /proc/sys/vm/swappiness". That means |
70 |
the kernel will /always/ prefer keeping cache, dumping the least used |
71 |
applications to swap where necessary. Conversely, people who run a |
72 |
single hard drive with both swap and most of their filesystem on it, who |
73 |
run an slocate updatedb cron job over night and come back to a really |
74 |
sluggish system the next morning because the kernel has swapped all their |
75 |
still loaded firefox tabs and the like out in favor of caching what |
76 |
amounts to the single-shot updatedb data, may wish to set swappiness |
77 |
lower than the default 60, say 20, or even 0, at which point the system |
78 |
would always favor the apps and always dump cache, when it came to that |
79 |
point. |
80 |
|
81 |
However, the BIG payoff of lots of memory (4 gig or so being a sweet spot |
82 |
for this), particularly for Gentoo systems or anyone else doing a lot of |
83 |
"temp" work, compiling or the like, is to setup a large (several gig) |
84 |
tmpfs and do all your compiling and stuff there, only copying the |
85 |
completed files over to the main non-volatile filesystem. On Gentoo, |
86 |
it's particularly easy to use a tmpfs for compiling and the like, by |
87 |
simply setting the appropriate PORTAGE_TMPDIR and similar variables in |
88 |
make.conf. With "only" four gig of memory, however, and with certain |
89 |
packages requiring sizable work areas (OOo is said to require on the |
90 |
order of 4-5 gigs!), trying this without swap risks severe memory |
91 |
shortage situations. I have a full 8 gig memory and a 5 gig tmpfs /tmp |
92 |
(with portage pointed to it) here, and even with 8 gigs memory, if I try |
93 |
emerging several things in parallel, it's not unusual to see active swap |
94 |
as a result. On a four gig system, I'd DEFINITELY want swap backup if I |
95 |
had PORTAGE_TMPDIR and friends pointed at tmpfs (which I might then try |
96 |
at 3 GB max size, tho obviously that wouldn't work if I tried to compile |
97 |
OOo or something nearly as big). |
98 |
|
99 |
It's worth repeating. A tmpfs based PORTAGE_TMPDIR is probably the |
100 |
single best use for 4 gig of memory on a normal Gentoo system, but it's |
101 |
not something I'd recommend anyone try without swap. Therefore, I'd |
102 |
recommend a tmpfs be setup for portage to use, and that swap remain |
103 |
enabled for the system to use in the event it needs it when portage is |
104 |
compiling something big. To try to setup that tmpfs for portage to use |
105 |
/without/ swap enabled... might be OK on an 8 gig system tho I'm not |
106 |
going to try it myself, but is certainly risking trouble and instability |
107 |
on a 4 gig system. |
108 |
|
109 |
Finally, note that the in-kernel hibernate (aka suspend to disk) |
110 |
functionality requires a dedicated swap partition of sufficient size. |
111 |
Suspend to disk is /finally/ working here, and it's a nice feature to |
112 |
have. However, it /does/ require swap space to suspend into. (Note that |
113 |
the swap partition doesn't have to be the full size of RAM. Each of my |
114 |
swap stripes is only 4 gig, making 16 gig of swap available, but suspend |
115 |
will only use one stripe, so 4 gig. I have 8 gig memory but only a 4 gig |
116 |
swap stripe partition to suspend to, but it works fine.) If you are |
117 |
using a non-vanilla kernel with the Suspend2 patch, or something similar, |
118 |
this may or may not apply, as I think it's possible for it to use a non- |
119 |
swap suspend file. However, with the mainline in-kernel suspend, at |
120 |
least last I read, it requires swap. That's actually why I re-enabled |
121 |
swap here, tho it was quite some time before I could actually get suspend |
122 |
to disk to actually work as advertised. I kept swap enabled and would |
123 |
try it every few kernel versions, and it finally started working! |
124 |
|
125 |
So in summary, four reasons to keep swap enabled: |
126 |
|
127 |
1) Old kernels needed it for memory zone management. (N/A for a decently |
128 |
modern kernel, say 2.6.16 or newer.) |
129 |
|
130 |
2) Memory mapped file flexibility. |
131 |
|
132 |
3) tmpfs based PORTAGE_TMPDIR and friends is generally a MUCH more |
133 |
efficient use of several gigs of memory than turning off swap, but until |
134 |
you have I'd say 6 gigs memory minimum, you'll want to keep swap enabled |
135 |
if you do it. |
136 |
|
137 |
4) Suspend to disk, aka hibernate, uses swap. |
138 |
|
139 |
#3 and possibly #4 are the important ones. |
140 |
|
141 |
OTOH, disabling swap entirely, by turning off that config option in |
142 |
kernel setup before compiling it, DOES significantly simplify kernel code |
143 |
and memory management. This was in fact the reason I had it off back |
144 |
when I had only a gig of memory. I had system stability issues due to |
145 |
unstable memory hardware (cheap memory) at the time, and I figured the |
146 |
less complicated kernel memory management was, the more stable the system |
147 |
was likely to be. I don't know if it made much of a difference, but it |
148 |
definitely wasn't LESS stable. (The memory zone issues did apply back |
149 |
then, but my hardware simply wasn't stable enough for that to be much of |
150 |
an issue.) |
151 |
|
152 |
-- |
153 |
Duncan - List replies preferred. No HTML msgs. |
154 |
"Every nonfree program has a lord, a master -- |
155 |
and if you use the program, he is your master." Richard Stallman |
156 |
|
157 |
-- |
158 |
gentoo-amd64@g.o mailing list |