Skip site navigation (1)Skip section navigation (2)
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>