Date: Wed, 25 Jul 2001 01:01:38 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: "David O'Brien" <obrien@FreeBSD.ORG>, Mike Silbersack <silby@silby.com>, arch@FreeBSD.ORG, Bosko Milekic <bmilekic@technokratis.com>, "David O'Brien" <nobody@nuix.com> Subject: Re: cvs commit: src/sys/netinet tcp_usrreq.c Message-ID: <3B5E7CE2.C6A4EE4B@mindspring.com> References: <20010718121851.B26558@dragon.nuxi.com> <20010718214902.H6519-100000@achilles.silby.com> <20010724205513.H5825@dragon.nuxi.com> <200107250516.f6P5GG541239@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. If we do that it will remove or greatly reduce one of > the many problems we have to deal with. Then if someone decides to shift > the kernel start address down we can simply assume that that means they > want even *more* KVM space. The real and KVM scaling code would take > care of the rest. Please do not do this. The FreeBSD footprint is already over 8M for a minimal install, which is ridiculous; I frequently did 386BSD in 4M, and cut down versions in 1M, and FreeBSD 1.x would install in 4M as well, without a lot of trouble. Burning 1M on page tables under the assumption that you'll have 1G or more of RAM is a _very_ bad idea. Handling additional page tables is the job of "growkernel". Personally, I run with most everything in 4M pages, which means a drastically reduced page table cost, but that is obviously not for everyone. I _do not_ currently recover the pages burnt for page tables set up before the VM is really up, which means that that 1M you waste won't be recoverable for me, at all (and I think I'm in the best position of anyone out there to recover it, right now). You would do much better to fix the startup code to do the right thing, rather than eliminating what I consider a very useful feature: sparse initial page table allocation. Also, be aware, if you were to produce an allocator that was not type stable for interrupt level allocations using anonymous backing pages for which entries exist, but pages do not, you would need to also resolve the isue, instead of sweeping it under the rug of static preallocation like this... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B5E7CE2.C6A4EE4B>