From owner-freebsd-arch Wed Jul 25 1: 9:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 6583637B403 for ; Wed, 25 Jul 2001 01:09:23 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.141.74.Dial1.SanJose1.Level3.net [209.245.141.74]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id BAA20060; Wed, 25 Jul 2001 01:09:11 -0700 (PDT) Message-ID: <3B5E7ECE.2060AD2C@mindspring.com> Date: Wed, 25 Jul 2001 01:09:50 -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: Peter Jeremy Cc: Matt Dillon , arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet tcp_usrreq.c References: <20010718121851.B26558@dragon.nuxi.com> <20010718214902.H6519-100000@achilles.silby.com> <20010724205513.H5825@dragon.nuxi.com> <200107250516.f6P5GG541239@earth.backplane.com> <20010725162426.R506@gsmx07.alcatel.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Peter Jeremy wrote: > > 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. I concur: scalability first, overoptimization at the expense of scarce resources second (if ever). > 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). Not really. The problem is the free reserve in user space, and user space mappings wanting (a) contiguity and (b) sparseness. > [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. You can allocate pageable kernel memory, it's just that most of the allocations are non-ppageable, and none of the kernel itself is, since we neither set nor respect the ELF attribute indicating "non-pageable" to protect things in our paging path (#pragma section(section_name)...). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message