Date: Sun, 11 Feb 2001 19:56:05 -0700 (MST) From: "Forrest W. Christian" <forrestc@imach.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: "Michael C . Wu" <keichii@iteration.net>, freebsd-small@FreeBSD.ORG Subject: Re: Sans-Swap VM Subsystem Questions Message-ID: <Pine.BSF.4.21.0102111925480.22351-100000@workhorse.iMach.com> In-Reply-To: <200102120109.f1C19DY01509@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt: You were who I was going to write to next, since it looks like you're one of the people who get their hands dirty in the vm portion kernel on the a regular basis. Thanks for the responses so far :) Of course, I have a few more questions. On Sun, 11 Feb 2001, Matt Dillon wrote: > What I would recommend for anyone running a SWAPless kernel for a turnkey > application is to either compile *ALL* programs -static, or try to > collapse all the shared libraries into a single shared library. In my instance, I crunchgen everything into one huge binary and hard link the names... Which now I think about it brings up another question, but I'll mention it below. The reason that I got thinking about this is that my crunchgen binary is getting rather large, and I'm sure that there are clean pages which may or may not be in use at a given time. I'd rather it free the clean pages than blow up due to lack of memory. > Even though -static increases the size of the binary image, it will > actually *REDUCE* the number of pages the kernel dirties in memory > when loading the program (e.g. because the kernel does not have to > mess around with relocations of library calls). And, even though > the RSS may be slightly higher, it will be made up of more clean pages. Assuming you have one big homogenous program which does everything you want (including init), and hard link multiple references to that one inode, does the kernel understand that it should share the code? Or better put, does the kernel actually look at the block/inode number on disk when it tries to figure out what it can and cannot share/free/etc? One additional kinda-related question.. In traditional PicoBSD, a memory disk is used to store the code which is actually copied off of the floppy. In this case, it would be cool if FreeBSD understood that the code actually resided in memory, and didn't make a second copy of it. Do you know if this is by chance the case? If it is, I'm seriously impressed with whoever wrote that code...I'm still thinking about the cans (cases?) of worms that could be. > The kernel has no problem freeing up clean pages (backed by the original > binary images in the flash memory), whereas without swap the kernel has > no way to free up dirty pages. Ok, then this brings us back to the following options: options NO_SWAPPING (in the kernel config file) vm.swap_enabled (sysctl) vm.defer_swapspace_pageouts vm.disable_swapspace_pageouts (and probably a whole slew of others). In regards to options NO_SWAPPING, lint says it removes the swapping code from the kernel. From the looks of things, it takes a *LOT* of the VM subsystem with it. I realize there is some controversy over if this is safe or not, but past experience shows that it doesn't seem to make anything less stable. The question is whether freeing a clean page is considered swapping in this context, or whether it just means actual swapping of a dirty page. For the others, I mainly want to make sure that they generally don't really matter in the context of not even having a swap partition on disk. Are the sysctl options *really* documented anywhere? > I also strongly recommend running with the 'H' malloc.conf option > (see 'man malloc'). Am I reading the man page correctly that the way to set this is: ln -s H /etc/malloc.conf > Beyond that, you have to be very, very, very careful in how you write > the programs that will run under such a system. Remember, clean pages > are essentially free, dirty pages cost memory. I have a feeling that the next stage of this project is nailing memory leaks..... - Forrest W. Christian (forrestc@imach.com) AC7DE ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ---------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0102111925480.22351-100000>