Date: Mon, 12 Feb 2001 02:09:50 -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.0102120143070.23698-100000@workhorse.iMach.com> In-Reply-To: <200102120610.f1C6AfO02706@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 11 Feb 2001, Matt Dillon wrote: > The other alternative is to statically link the individual binaries > separately. This will result in a larger amount of space taken up in > the flash, but if you are only running one or two binaries > predominantly the memory footprint will be excellent because the > memory footprint for the 'idle' programs or the ones not being run > will be zip. In this application (and I'd imagine a lot of the "small" BSD builds), I can probably divide each utility into a couple of sets. There is a chunk of code (such as the equivalent to init, sh, and probably things like inetd, etc.) which will almost 100% of the time be resident. There is yet another chunk of stuff (like ps, ee/vi, etc) which is rarely resident - primarily during interactive sessions which shouldn't happen all that often. Of course, there are also things which may or may not be active depending on the configuration. It sounds like keeping the always-resident (and active) code in a big statically linked binary is probably a good idea, and perhaps moving some of the non-typically ran applications out into their own binary(s) would be good. I can think of at least one or two apps that grab a LOT of libraries and pieces of clib which aren't in use elsewhere which I could easily move out. I do realize that there is a tradeoff, as having two or more statically linked can't share the portions of libc which they share. It's too bad there isn't an optimization flag to ld (or gcc) which somehow optimizes statically linked binaries so that related code (including libraries) are together, and thus lets the paging system be more efficient. > I'm not sure what picobsd is using, but its probably MFS. With MFS > every active page will take up 2x the memory and every inactive page > will take up 1x the memory (verses no memory if your backing store is > some native device, like a flash rom). This is consistent with what I was thinking. I'll have to dig around through "md" and see if it looks like it actually solves this. But since, I'm not running from a ramdisk anymore I probably won't be digging anytime soon ;) > NO_SWAPPING should be fine, though I don't think I've ever used the > option myself so you should make sure that the kernel still operates > properly with it set. AFAIK, NO_SWAPPING doesn't appear to break the kernel (I have at least 4-5 machines out there with it enabled with no problem). Is there a quick and dirty way I can tell if the clean page frees are being done or not? - 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.0102120143070.23698-100000>