Date: Sat, 11 Jul 1998 09:25:11 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: current@FreeBSD.ORG Subject: Re: Arrgh ! resubscribing again again again.... Message-ID: <199807110925.CAA16987@usr08.primenet.com>
next in thread | raw e-mail | index | archive | help
> This problem in the VM Subsystem persists since around mid of January > 1998 and ther was already a thread on this lists about "dying daemons". [ ... ] > Jun 3 16:10:20 magnet /kernel: swap_pager: suggest more swap space: 61 MB > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > This comes from starting netscape 4.05 > > and now: > > Jun 3 16:12:17 magnet su: holm to root on /dev/ttyp3 > Jun 3 16:15:10 magnet su: holm to freebsd on /dev/ttyp2 > Jun 3 16:31:43 magnet /kernel: pid 3385 (sendmail), uid 0: exited on signal 11 > > This is what I mean ! This is normal. FreeBSD VM uses a memory overcommit architecture. This means data pages are marked "copy on write" and pulled from the swap store (in this case, the vnode) until such time as a write occurs. When a write to the page occurs, it becomes "dirty", and the page is copied as a result of a write fault. When no backing pages exist (becaues you've used them all up and are out of swap space), the process requesting the page as a result of the copy on write fault can not have its request satisfied. The result of an unsatified fault request is a SIGSEGV, or signal 11; this is because the page you are writing does not exist (since the system was unable to allocate it on your behalf; like dereferencing a NULL pointer, it means "the page you tried to write/read can not be written/read"). This is a normal result of not reserving all possible memory a program needs when the program is invoked (which, if it failed, would give an "out of resources error" to the fork(2) call or execve(2) call, instead). The problem is complicated by the fact that programs which use malloc(3) call sbrk(2) to increase their heap, and stack depth increases can result in similar needs for pages, even if the data pages were committed up front. This means that to totally solve the problem, you would have to commit real pages in swap or system memory not only for the data pages that may be written that you know about, but that the programmer would also need to estimate the number of additional pages that the program will ever need for dynamically allocated data space and/or stack, and get backing store (in real or virtual memeory) for those, as well. Not only is this impractical (because of the way the FreeBSD libraries are programmed), most programmers who were taught on or after about 1982 simply don't know how to make this calculation; they were never taught the concept that it was possible for there to be a system where memory wasn't "free". The general fix for this problem is to provide more than sufficient swap space for the system as a whole, and then use "limit" (or login.conf) to limit the portion of that space which can be consumed by a single process. Done correctly, this will result in your Netscape process or X11 server failing from hitting the soft limit before the system starts failing from hitting the hard limit. Of course, many times, the soft limit is set higher than the hard limit by people annoyed by login.conf, and who simply do not understand the consequences of their actions. Per the memory leak in Netscape: when you start your X11 server, if you disable the shared memory extensions, or you run your Netscape from a machine other than the one you are running the X server on (which will prevent it from using the shared memory extensions, which can only be used by local X11 programs), then you should see the memory leak go away. This is the only documented (ie: "proven") workaround for this problem at this time, short of setting soft limits that will cause Netscape and/or X11 to fail spectacularly. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807110925.CAA16987>