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
> -#define NKPT 32
> +#define NKPT 1023
> #endif
>
> #define NKPML4E 1 /* 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 @@
> */
>
> #define VM_MAX_KERNEL_ADDRESS KVADDR(KPML4I, NPDPEPG-1,
> NPDEPG-1, NPTEPG-1)
> -#define VM_MIN_KERNEL_ADDRESS KVADDR(KPML4I, NPDPEPG-7, 0, 0)
> +#define VM_MIN_KERNEL_ADDRESS KVADDR(KPML4I, 0, 0, 0)
>
> #define DMAP_MIN_ADDRESS KVADDR(DMPML4I, 0, 0, 0)
> #define DMAP_MAX_ADDRESS KVADDR(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]"
