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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
