From owner-freebsd-current Fri Feb 6 20:34:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA05613 for current-outgoing; Fri, 6 Feb 1998 20:34:36 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA05577; Fri, 6 Feb 1998 20:34:24 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id VAA03766; Fri, 6 Feb 1998 21:34:18 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd003742; Fri Feb 6 21:34:14 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA25379; Fri, 6 Feb 1998 21:34:09 -0700 (MST) From: Terry Lambert Message-Id: <199802070434.VAA25379@usr05.primenet.com> Subject: Re: Custom init(8) (and some ideas) To: dyson@FreeBSD.ORG Date: Sat, 7 Feb 1998 04:34:09 +0000 (GMT) Cc: mike@smith.net.au, abial@nask.pl, tlambert@primenet.com, freebsd-current@FreeBSD.ORG, jkh@FreeBSD.ORG In-Reply-To: <199802070350.WAA00681@dyson.iquest.net> from "John S. Dyson" at Feb 6, 98 10:50:01 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe current" > I think that I might have misinformed here. Gzipped binaries need swap > backing store for each page in the image even for .text section, when > physical memory space needs to be freed for another page. Non-gzipped > binaries can depend on paging off of the a.out itself. Also, non-gzipped > binaries don't have to page out the .text for the initial freeing of the > .text space. Gzipped binaries need to page out the .text pages when they > are individually freed due to pageout daemon activity. Also, gzipped > binaries are not demand-loaded, but are loaded at startup. This guarantees > that the entire image will have to be supported by either memory or swap > space. During normal program execution (normal a.out, ELF, etc), the > entire image doesn't have to be initially loaded, and you can get > by with the size of the image being larger than the size of physical > memory + swap space (of course, that is a special case need, but it is > possible to do.) In the case of a gzipped binary, that isn't true. What is the compression table flush boundry? You *could* use the gzip'ped file as a swap store, *if* you created pages out of the file on the flush boundry, since you could re-decompress the needed pages by restarting from that point. This would require (basically) a gzip-pager. You would also need to make an map (probably an RLE 0/1 bitmap) to know how many full and partial pages each decompressed to, and handle the section boundries (since they would probably not decompress to even page boundries). Heh. Feels like "SoftRAM". 8-) 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.