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
