Re: Time to bump default VM_SWZONE_SIZE_MAX?

On Tuesday, August 14, 2012 02:47:47 AM Dag-Erling Smørgrav wrote:
> Colin Percival <cperciva_at_freebsd.org> writes:
> > If I'm understanding things correctly, the "maxswzone" value -- set by
> > the kern.maxswzone loader tunable or to VM_SWZONE_SIZE_MAX by default --
> > should be approximately 9 MiB per GiB of swap space.
> 
> Far less, in fact.  As mentioned in loader(8), the default 32 MB limit
> is enough for slightly more than 7 GB of swap space - assuming 100%
> efficient use of swblocks.  The man page recommends not using more than
> half the theoretical limit, or, with 16 pages per swblock,
> 
>                           1     maxswzone x s
>                          --- x ---------------
>                           2          16
> 
> where s = 276 on 32-bit systems and 288 on 64-bit systems.
> 
> > The current default for VM_SWZONE_SIZE_MAX was set in August 2002 to 32
> > MiB; meaning that anyone who wants to use more than ~ 3.5 GB of swap
> > space ought to set kern.maxswzone in /boot/loader.conf.
> > 
> > Is it time to increase this default on amd64?  (I understand that keeping
> > the value low on i386 is important due to KVA limitations, but amd64 has
> > far more address space available...)
> 
> There is no reason to keep this limit at all.  The algorithm used to
> size the zone is "physpages / 2 * sizeof(struct swblock) or maxswzone,
> whichever is smaller" where maxswzone == VM_SWZONE_SIZE_MAX unless
> kern.maxswzone was set in loader.conf.  On amd64, the cutoff point is
> slightly below 1 GB of physical memory (233,016 4,096-byte pages), so
> the limit doesn't help machines that actually need to conserve memory,
> and it hurts machines that have plenty of it and therefore also plenty
> of swap (assuming the user followed the old "twice the amount of RAM"
> rule of thumb).

Hmm, this is not true on i386 where the problem is not just the physical
RAM required, but also address space.  (The swap zone is all mapped into KVA 
even if it isn't used.)  This is why Alan's e-mail specifically
mentioned amd64, ia64, etc. but not i386 in his list.  I think i386 still
needs this limit, and I think your commit jumped the gun a bit.

-- 
John Baldwin