2.6 swapping behavior
Posted May 6, 2004 18:42 UTC (Thu) by
Duncan (guest, #6647)
Parent article:
2.6 swapping behavior
Some weeks ago, as I was reading about yet more machinations and hoops the
kernel has to go thru to efficiently handle swap, I realized that with a
gig of memory and seldom more than half of it used by apps, I really
didn't need swap at all, so I turned it off.
I've been running without swap since then, to no bad effect and perhaps a
slightly more responsive system, if I'm to believe the "feel" of things.
The biggest surprise, however, was when I did the recompile with swap
compiled out of the kernel. Normally, changing a single option in a tree
that's already compiled the kernel and hasn't been cleaned from doing so
means a rather speedy recompile, as only a couple of C files worth of code
actually has to be recompiled. Not so with the swap option! Just that
single config change meant recompiling almost the entire kernel, it would
seem. I didn't realize swapping code was THAT deeply interwoven into
nearly every aspect of kernel operation, but it obviously is. Thus,
without all that extra swapping code to deal with, the kernel SHOULD be
faster.
I DID have to modify my startup and shutdown scripts, as it seems unlike
everything ELSE, where Mandrake (my current distrib) checks to see if the
files are actually there before attempting to operate on them, their init
scripts simply ASSUME the swap related /proc files will be there, and I'd
just turned them off. However, that was easily done, and I've been swap
free for a month or possibly six weeks, now.
My system is for desktop use, mainly, altho I AM running an AMD64 so have
64-bit code taking up a bit more memory than 32-bit would. Still, running
the not exactly light KDE, and all my regular apps, I seldom use more than
half a gig for app memory, with the other half in cache. Thus, the system
works well without swap. I'd not recommend the solution for graphical
X-system desktop use, however, for anyone with less than half a gig of
memory, and preferably more, 768M, leaving plenty of caching room, even
with a decent compliment of desktop apps running. That half-apps
half-cache rule of thumb seems pretty good, but with a lighter window
manager and 32-bit, 384M for each seems reasonable, yielding the 768M I
mentioned. Console mode only or lighter X use may well use only 256M of
app memory, which leaving the same for cache means 512M. With modern
graphical apps, that may be a bit small and keeping a swap around may be a
good idea, but that's where the 0 swapability config this article
mentions, comes in. However, with the cost of memory, now days, unless
one is stuck on an old hardware platform with limited memory
upgradability, there's little reason not to have at least half to 3/4 gig
of memory in the system, and upgrading to a gig is likely to increase
performance more than that last notch in CPU speed would.
When I upgrade to 2 or 4 gig, 6 months or a year from now, I'll probably
turn tmpfs back on, and put /tmp and /var/tmp in physical memory rather
than disk, as well.
Duncan
(
Log in to post comments)
