I could apply such a patch to my servers, but there are two disadvantages :
o who wants to apply kernel patches to mission critical servers? Isn't
that a linux thing (joke!)
o what about apps like the linuxulator that might not stand for this?
On the tunable option : with today's kmem_size and kmem_size_max
tunables, would there also be a need to tune the portion of address
space available to kmem?
Thanks,
Barry
Kris Kennaway writes:
Barry Boes wrote:
With the advent of ZFS, Solaris users are devoting 30G or more to
their ARC caches today. If FreeBSD 8 is going to up the KVM size, is
there a reason to not increase the limit to something that will not be
reached in the lifetime of 8? 100GB?
It's easily configurable on HEAD. From an email alc sent me:
This:
Index: amd64/include/pmap.h
===
--- amd64/include/pmap.h(revision 180373)
+++ amd64/include/pmap.h(working copy)
@@ -111,7 +111,7 @@
/* Initial number of kernel page tables. */
#ifndef NKPT
-#defineNKPT32
+#defineNKPT1023
#endif
#define NKPML4E1 /* number of kernel PML4
slots */
Index: amd64/include/vmparam.h
===
--- amd64/include/vmparam.h (revision 180373)
+++ amd64/include/vmparam.h (working copy)
@@ -163,7 +163,7 @@
*/
#defineVM_MAX_KERNEL_ADDRESS KVADDR(KPML4I, NPDPEPG-1,
NPDEPG-1, NPTEPG-1)
-#defineVM_MIN_KERNEL_ADDRESS KVADDR(KPML4I, NPDPEPG-7, 0, 0)
+#defineVM_MIN_KERNEL_ADDRESS KVADDR(KPML4I, 0, 0, 0)
#defineDMAP_MIN_ADDRESSKVADDR(DMPML4I, 0, 0, 0)
#defineDMAP_MAX_ADDRESSKVADDR(DMPML4I+1, 0, 0, 0)
will now get you this:
vm.kvm_free: 547729960960
vm.kvm_size: 549755809792
on HEAD. :-)
Kris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
