From owner-freebsd-hackers Tue May 8 9: 4: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by hub.freebsd.org (Postfix) with ESMTP id E4AA637B422 for ; Tue, 8 May 2001 09:04:00 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (pool0302.cvx21-bradley.dialup.earthlink.net [209.179.193.47]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA03387; Tue, 8 May 2001 12:03:56 -0400 (EDT) Message-ID: <3AF81901.A5315CA3@mindspring.com> Date: Tue, 08 May 2001 09:04:17 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Aman Cc: "freebsd-hackers@freebsd.org" , "Sandeep (ROCK MAN)" , Jaswinder Singh Kohli Subject: Re: squeeze freeBSDs' kernel size References: <3AF50686.F09BBDD5@runbox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Aman wrote: > > kldstat shows the kernel as a loaded module. does it mean > the kernel after getting in the core is resident to it's > complete physical size. Its complete physical size... only including static BSS allocations. > my question is, does the pagedaemon carry out any sort of > paging or segmentation on the kernel and it's loadable > modules though the latter seems necessary. The inpcb's, tcpcb's, and similar data allocated via zalloci() are in fact allocated in pageable memory. These are post initialization allocations (and are very annoying, since their allocations apparently _must_ be contiguous in the address map, so they must be per-sized to a large size, if you ever expect to open a lot of sockets). > how much size can be really squeezed out of the kernel Not a lot, unless you reduce resources available to user space. For example, a properly cut-down kernel that does not load unnecessary modules can still run in 4MB. For most useful applications these days, networking is required, which tends to bloat things up a bit more than might be desirable. One big factor here appears to be the unnecessary mbuf allocation for each socket, and the IPv6 stuff. It appears to be very difficult to make the IPv6 stuff "Go Away!" gracefully, without still bloating some kernel structures; part of that appears to be the fact that it's not really tagged very well as to what is IPv6 vs. what's IPv4... my guess is that the IPv6 people really, really didn't want us ripping IPv6 back out, once they were able to get it into the kernel. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message