On 2/13/07, Kevin Brosius [EMAIL PROTECTED] wrote:
On 2007-02-12 20:30, Dan Streetman wrote:
On 2/11/07, Kevin Brosius [EMAIL PROTECTED] wrote:
On 2007-02-05 20:24, Dan Streetman wrote:
On 2/5/07, Nicolas Maufrais [EMAIL PROTECTED] wrote:
Heroine Virtual Ltd recommends disabling swap when a lot of memory is
installed.
This is not a good idea under any circumstances. Disabling swap will
never help anything or improve performance, ever. It will only cause
the system to start killing processes when you use up all system
memory. Do not disable swap.
Hi Dan,
This will only be true for kernels with the OOM killer running, right?
It's irrelevant; whether you have it or not, if you have swap disabled
and run out of real memory, then real bad things will happen.
The only reason I know this is because I used to be able to build an
xfree86 source tree, and a second compile could sometimes run without
disk access. That tree was on the order of 100M at the time. I could
imagine that disk cache might have been weighted poorly in the paging
algorithm at some point. If that was half the mem, then the swap
comments above might be related to that. Remember, we are talking about
Cin usage, which would be disk intensive for render writes/reads, along
with page hungry for effects processing. The mix may be different for
single app usage than the test case you suggest below.
The disk caching is interesting, because with the advent of reiser, and
slightly newer kernels, I noticed that disk caching was nothing like
ext2. It would not cache an entire 100M source code true when accessed
with reiser, although that may have been an artifact of slightly newer
kernels. I do not recall if I tested that or not.
So, you think disk caching has no impact? Possible, I haven't tried
testing on a 4G machine.
Disc caching is irrelevant to swapping. Linux will use _all_ free
(real) memory for disc caching, and reduce the cache as programs
request more and more memory to actually use. When the actual memory
used by system programs approaches real memory limits, the cached
memory will approach 0.
How much sense does it make to swap out disc cache? ;-)
Maybe you would like to try it yourself like I suggested? I'll make
it easy, I've attached a very small trivial program that will quickly
eat up all your system memory. Run it first with swap enabled and
then without. Compile with gcc -o memory-eater memory-eater.c
If you want to bring disc caching into it, do:
dd if=/dev/zero of=/tmp/big-file bs=1024k count=4k ; memory-eater
note the 4k is 4G of ram, if you have less just use a smaller
number, as the disc cache obviously can't exceed real system memory :)
I also attached 4 images from when I did this on my system, which
hopefully will show you that what I am saying is true; swapping does
not happen until real system memory is used up, and disc caching is
completely irrelevant to swapping. (#1 is after disc cache reaches
real system memory - no swap used, #2 is when real used memory
reaches/slightly exceeds real system memory - no cache, small swap, #3
is showing continued swap usage - no cache, #4 is after killing the
program)
And a final note, when you run that program with swap disabled, the
kernel's OOM killer will probably kill only that program. You can
disable the OOM killer (at least, man malloc says you can...) by
doing echo 2 /proc/sys/vm/overcommit_memory, so if you want you
can try it without swap _and_ without the OOM killer I'd be interested
to hear what happens there! ;-)
memory-eater.c
Description: Binary data
memory-eater1.gif
Description: GIF image
memory-eater2.gif
Description: GIF image
memory-eater3.gif
Description: GIF image
memory-eater4.gif
Description: GIF image
