Date: Fri, 06 Feb 1998 19:32:58 -0800 From: Mike Smith <mike@smith.net.au> To: Andrzej Bialecki <abial@nask.pl> Cc: Terry Lambert <tlambert@primenet.com>, freebsd-current@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Custom init(8) (and some ideas) Message-ID: <199802070332.TAA03469@dingo.cdrom.com> In-Reply-To: Your message of "Thu, 05 Feb 1998 10:40:21 %2B0100." <Pine.NEB.3.95.980205100537.18163B-100000@korin.warman.org.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
> A bit of background, if you're interested: I'm working on the next version > of PicoBSD, and after some shuffling with the layout and adding new > features I found that I can no longer fit into 8MB RAM... I.e. it fits, > but I can't start enough processes to make a dialup connection. What does the process listing look like? (use ddb and the 'ps' command rather than try to squeeze 'ps' into the crunch image). > There was one really nasty surprise which I experienced: the way the > gzipped binaries are executed. It wastes a LOT of RAM. How else would you do it? You can't easily page off an LZW-compressed image (for obvious reasons), so you have to put the uncompressed thing *somewhere*. Have you shrunk the kernel as much as possible? > I had some ideas how to fix it, but the implementation of this is far > beyond my knowledge: to modify imgact_gzip NOT to load the gzipped binary, > but just to mmap it, and then unpack it. When I asked John Dyson he said > that it would require a lot of work to change it... Pity. I'm not sure I follow you there. The imgact_gzip code doesn't load the gzipped binary at all; it mmap's it one page at a time, uncompressing it as it goes. > Also, IMHO it would be a good option to the kernel and/or ld.so to tell > them not to load .text at all (it could apply to .text section of binaries > as well as shared libs), just to mmap it, if the backing filesystem is of > MFS type. For non-gzip binaries, execution starts by mmapping the entire text section, and jumping to it. Nothing is "loaded" in any case. What you're suggesting really is "execute-in-place", which is quite a tough thing to implement. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802070332.TAA03469>