From owner-freebsd-hackers Mon Jun 18 22:39:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ip.eth.net (mail.ip.eth.net [202.9.128.18]) by hub.freebsd.org (Postfix) with ESMTP id CEBB337B401 for ; Mon, 18 Jun 2001 22:39:33 -0700 (PDT) (envelope-from asr@softhome.net) Received: (apparently) from vangogh.indranetworks.com ([61.11.16.239]) by ip.eth.net with Microsoft SMTPSVC(5.5.1877.467.46); Tue, 19 Jun 2001 11:08:59 +0530 Date: Tue, 19 Jun 2001 11:15:01 +0530 (IST) From: "Ashutosh S. Rajekar" To: Matt Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: max kernel memory In-Reply-To: <200106181757.f5IHvKK16658@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 18 Jun 2001, Matt Dillon wrote: > > DG changed KERNBASE a while back to reserve a gigabyte of VM for the > kernel. This should be sufficient on a 4G machine but it depends where > your resources are going. If your server's resources are user-process > centric then you don't need to change KERNBASE. If your server's > resources are network-mbuf centric then you may have to give the kernel Most of the resources will go into mbufs, clusters, socket structures, PCBs, etc. I mean, supporting a million TCP/IP connections is the primary goal. If setting aside more memory for kernel usage doesn't work out, then I guess I'll have to have some user-level dummy processes that just hold memory for me, and pass it on whenever required. But memory bandwidth is still going to be an issue. (not to forget user-kernel switches, user-kernel copy, etc.). > more KVM (e.g. like 2GB instead of 1GB... 0x80000000 instead of > 0xC0000000). But be careful. The more KVM reserved for the kernel, the > less VM is available for user processes to allocate and mmap. > I'm sure people who run 4G machines can give you better information, I've > never run anything larger then 2G myself, though expect down the line > I'll begin needing 4G machines to support larger databases. An associated question: along with this, changing the kernel to use only PDEs should be better for TLB performance. Mapping 4Mb at a time would definitely be much better than 4k. I'm talking of having the entire kernel (at least the code) find mappings in the TLB, and keeping 4Mb mappings might just do the trick. I did see pmap_kmem_choose() being called pretty early in pmap_bootstrap(), but it looks like it's doing that for a single page; what I want is to have 4M mappings for all pages in the system. Or have I overlooked something ? Any comments ? -ASR --------------------------------------------------------------------- ("`-''-/").___..--''"`-._ (\ Indra Networks Pvt. Ltd `6_ 6 ) `-. ( ).`-.__.`) Pune, INDIA. (_Y_.)' ._ ) `._ `. ``-..-' mailto: asr@softhome.net _..`--'_..-_/ /--'_.' ,' http://www.rajekar.org (il),-'' (li),' ((!.-' http://www.indranetworks.com --------------------------------------------------------------------- There is more simplicity in the man who eats caviar on impulse than in the man who eats Grape-Nuts on principle. -- G.K. Chesterton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message