kernel - Increase KVM default for 32-bit systems from 1GB to 1.5GB
authorMatthew Dillon <dillon@apollo.backplane.com>
Thu, 13 Jun 2013 20:23:38 +0000 (13:23 -0700)
committerMatthew Dillon <dillon@apollo.backplane.com>
Thu, 13 Jun 2013 20:23:38 +0000 (13:23 -0700)
* Increases KVA_PAGES default from 256 to 384, giving the kernel 1.5GB
  of KVM and userland 2.5GB (instead of 1/3).

Numerous people running 32-bit systems are hitting resource limits and
actually running out of KVM.  There are many reasons for why this is
happening.  It isn't simply a resource-tuning issue because most of the
resource limits we have today are already quite reasonable.  It's when
the system combines to fully utilize multiple resources where the problems
begin.  Tuning-down the resources impacts performance too much and makes
the systems less usable.  PCI resources tend to reserve larger areas,
system structures are fatter, and many other issues crop up.

In addition, 32-bit systems today can be greatly extended by adding swapcache
and swapcache requires significantly KVM resources.  For example, adding
64GB of swapcache eats ~64MB of ram and heavy tmpfs use often requires an
even higher ratio (64GB swap w/ kern.maxswzone=128m in /boot/loader.conf).
With the price point for SSDs coming down, 256GB and larger SSDs are far
more common these days and we want even 32-bit systems to be able to make
use of them.

On a fresh system boot well over 512MB of KVM out of the (previous) 1GB
space is already accounted for.  This leaves precious little for dynamic
expansion of system structures.

This leaves us with one real option... increase KVM and decrease UVM.
By increasing KVM from 1GB to 1.5GB we nearly double the KVM available to
the kernel for dynamic expansion of system structures.  User virtual memory
is reduced from 3GB down to 2.5GB.  While this may impact some applications
such as Perl, those applications are already tending to run on the edge
anyway and, in fact, modern application development is starting to assume
64-bit address spaces for optimal operation anyway.

I've come to the conclusion that it is better to move the line on UVM down
in order to completely solve the KVM issue for system resources on 32-bit
systems.

sys/platform/pc32/include/pmap.h

index ca92995..8e319a5 100644 (file)
  * Size of Kernel address space.  This is the number of page table pages
  * (4MB each) to use for the kernel.  256 pages == 1 Gigabyte.
  * This **MUST** be a multiple of 4 (eg: 252, 256, 260, etc).
+ *
+ * DEFAULT CHANGED 256->384.  32-bit systems have used 256 (1G KVM, 3G UVM)
+ * for many years, but all recent and continuing kernel development really
+ * assumes that more KVM is available.  In particularly, swapcache can be
+ * very effective on a 32-bit system with 64G or even more swap and 1GB of
+ * KVM just isn't enough to manage it.  Numerous subsystems such as tmpfs
+ * have higher overheads (e.g. when used with pourdriere), vnodes are fatter,
+ * mbufs are bigger and we need more of them, and the list goes on.  Even
+ * PCI space reservations have gone up due to Video subsystems.  On a
+ * freshly booted system well over 512MB of KVM is already reserved before
+ * the machine runs its first user process.
+ *
+ * The new default of 384 gives the kernel 1.5GB of KVM (2.5G UVM) and
+ * relieves the pressure on kernel structures.  This almost doubles the
+ * amount of KVM available to the kernel post-boot.
  */
 #ifndef KVA_PAGES
-#define KVA_PAGES      256
+#define KVA_PAGES      384
 #endif
 
 /*