Since we have increased the hard page table allocation for the kernel to
1G (?) we should be able to safely increase VM_KMEM_SIZE_MAX. I was
thinking of increasing it to 512MB. This increase only effects
large-memory systems. It keeps them from locking up :-)
Anyone have
:
: Yes, I do - at least with the 512MB figure. That would be half of the 1GB
:KVA space and large systems really need that space for things like network
:buffers and other map regions.
:
:-DG
:
:David Greenman
:Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Jason Thorpe wrote:
On Wed, 7 Jul 1999 17:03:16 -0700 (PDT)
Matthew Dillon [EMAIL PROTECTED] wrote:
If this could result in a smaller overall structure, it may be worth i
t.
To really make the combined structure smaller we would also have to
pair-down the fields in
:On Thu, 08 Jul 1999 08:36:19 +0800
: Peter Wemm [EMAIL PROTECTED] wrote:
:
: Out of curiosity, how does it handle the problem of small 512 byte
: directories? Does it consume a whole page or does it do something smarter?
: Or does the ubc work apply to read/write only and the filesystem
On Thursday, 8 July 1999 at 9:26:09 +1000, Peter Jeremy wrote:
David Greenman wrote:
Yes, I do - at least with the 512MB figure. That would be half of the 1GB
KVA space and large systems really need that space for things like network
buffers and other map regions.
Matthew Dillon [EMAIL
we already use the gs register for SMP now..
what about the fs register?
I vaguely remember that the different segments could be used to achieve
this (%fs points to user space or something)
julian
On Wed, 7 Jul 1999, Matthew Dillon wrote:
:Why not put the kernel in a different address
