From owner-freebsd-arch Tue Jul 24 23:24:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 03CB737B406 for ; Tue, 24 Jul 2001 23:24:45 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id QAA11392; Wed, 25 Jul 2001 16:24:29 +1000 (EST) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37641) with ESMTP id <01K6CRNS1FCGVFCCN9@cim.alcatel.com.au>; Wed, 25 Jul 2001 16:24:25 +1000 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f6P6OQ565918; Wed, 25 Jul 2001 16:24:26 +1000 (EST envelope-from jeremyp) Content-return: prohibited Date: Wed, 25 Jul 2001 16:24:26 +1000 From: Peter Jeremy Subject: Re: cvs commit: src/sys/netinet tcp_usrreq.c In-reply-to: <200107250516.f6P5GG541239@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Jul 24, 2001 at 10:16:16PM -0700 To: Matt Dillon Cc: arch@FreeBSD.ORG Mail-Followup-To: Matt Dillon , arch@FreeBSD.ORG Message-id: <20010725162426.R506@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <20010718121851.B26558@dragon.nuxi.com> <20010718214902.H6519-100000@achilles.silby.com> <20010724205513.H5825@dragon.nuxi.com> <200107250516.f6P5GG541239@earth.backplane.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Cc: trimmed] On 2001-Jul-24 22:16:16 -0700, Matt Dillon wrote: > I think KVM management has gotten to the point where we might as well > setup page tables for the entire 1GB, which will cost us 1MB of ram > for page tables. This is still a hit for small memory machines. 4.3-RELEASE states "minimum 16MB RAM" - 1MB a significant slice of this. > If we do that it will remove or greatly reduce one of > the many problems we have to deal with. Accepted. I think the idea of allocating page tables for KVM is worthwhile. I just think we need to make KVM scalable first. Would it be practical to move the kernel to the top of memory and have the KVM space grow down to a size determined by physical RAM (eg KVM is the same as physical RAM[1], capped to say 2GB) and then allocate page tables to suit. (This has the added advantage of not needing the kernel to be re-linked if you need >1GB KVM). [1] I don't think anything in KVM is currently pageable so it doesn't make sense to have more KVM than RAM. If this isn't true, or when we implement pageable KVM, we can increase the KVM to physical RAM ratio. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message