svn commit: r341103 - head/sys/powerpc/include

[Ian Lepore]

On Tue, 2018-12-04 at 05:56 +1100, Bruce Evans wrote:
> On Mon, 3 Dec 2018, Justin Hibbits wrote:
> 
> [...]
> 
> Please look at removing VM_KMEM_SIZE_SCALE completely.  I'm now trying to
> convince kib that it is bogus for all arches, but only know exactly what
> happens on x86.
> 
> On arches with large kva, the scale factor should be 1 or smaller since
> there is enough kva to map physmem several times.
> 
> On arches with small kva, the kmem size should be as large as possible
> and not depend on the physmem size (except as a micro-optimization for
> space), since large physmem needs maximal kva and small physmem doesn't
> require restricting kva.
> 
> The scale factor of 3 just breaks booting FreeBSD-11 i386 with 48MB
> physmem, by making kmem about 3 times smaller than it needs to be to
> map this whole 48MB.  The nmbclusters allocation runs out first on my
> test system, despite more overcommit for mbuf allocations than most.
> 
> Bruce
> 

I know we had problems with the default scaling on armv7 at $work when
we tried to embed a large (150mb) mdrootfs into our kernel for a system
with 2gb ram. I had to chase down the meaning of the scale variable
(and I certainly could have misunderstood it to any degree), but here's
what I wrote about it after fiddling and finding a value that worked
for us. This was for early incarnations of 11-stable.

# Tuning required to make the kernel work with a large
# embedded filesystem...
# 
# Allocate one page of kmem_arena KVA for every
# VM_KMEM_SIZE_SCALE pages of ram.  The default scale is 3,
# and with a huge (>100MB) embedded mdroot that doesn't leave
# enough virtual address space to allocate enough kernel
# stacks, mbufs, and other resources that come out of KVA.
options 	VM_KMEM_SIZE_SCALE=5

-- Ian