From owner-svn-src-all@freebsd.org Mon Dec 3 18:56:14 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F880132F61C; Mon, 3 Dec 2018 18:56:14 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 204948F056; Mon, 3 Dec 2018 18:56:12 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id B8EC63D9092; Tue, 4 Dec 2018 05:56:10 +1100 (AEDT) Date: Tue, 4 Dec 2018 05:56:09 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Justin Hibbits cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r341103 - head/sys/powerpc/include In-Reply-To: <20181203102007.4021aa32@ralga.knownspace> Message-ID: <20181204043712.F3059@besplex.bde.org> References: <201811280248.wAS2miqW055485@repo.freebsd.org> <20181128151148.X1660@besplex.bde.org> <20181203102007.4021aa32@ralga.knownspace> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=3ptsJk61p7z6p2NaEGMA:9 a=CjuIK1q_8ugA:10 X-Rspamd-Queue-Id: 204948F056 X-Spamd-Result: default: False [-4.87 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:211.29.132.0/23]; FREEMAIL_FROM(0.00)[optusnet.com.au]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[optusnet.com.au]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-1.56)[ipnet: 211.28.0.0/14(-4.31), asn: 4804(-3.45), country: AU(-0.04)]; MX_GOOD(-0.01)[cached: extmail.optusnet.com.au]; NEURAL_HAM_SHORT(-1.00)[-0.998,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; RCVD_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_LOW(-0.10)[42.132.29.211.list.dnswl.org : 127.0.5.1] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 18:56:14 -0000 On Mon, 3 Dec 2018, Justin Hibbits wrote: > On Wed, 28 Nov 2018 16:31:33 +1100 (EST) > Bruce Evans wrote: > >> On Wed, 28 Nov 2018, Justin Hibbits wrote: >> >>> Log: >>> powerpc: Fix the powerpc64 build post-r341102 >>> >>> VM_MIN_KERNEL_ADDRESS is now used in locore.S, but the UL suffix >>> isn't permitted in .S files. >> >> The UL suffix is arguably a style bug in .c files too. It was not >> even wrong (it had no effect) this case, but nearby code seems to be >> more broken. >> >> A ULL suffix would be unarguably a style bug everywhere. > > I'll take a closer look at this eventually. I'm in the process of > overhauling a lot of the Book-E bits to play nicer with loader, etc. > This does involve touching vmparam.h a lot, so I'll think about > cleaning it up for these cases as well. Thanks. >> ... >> The i386 vmparam.h has the following style bugs in this area: >> ... >> - bogus extra parentheses only for VM_KMEM_SIZE_SCALE. >> >> The existence and default value of this macro are also wrong. They >> were last almost correct when the default user/kernel split was 3/1 >> and the physical memory size was 3 or 4 GB. >> >> The default for the macro is 3, which is closely related to the >> split ratio. This value works to prevent overflow in kva size >> calculations when the physical memory size is larger than the total >> kva size but less than 3 or 4 GB. Overflow still occurs for PAE >> since then the memory size can be larger than 4GB. Other magic >> properties of 3 result in the overflows giving reasonable values for >> the kva sizes when the memory size is 8GB or 16GB, but not when it is >> 12GB (because 12GB / 3 = 4GB = 0GB after overflow, and 0GB is not a >> useful kva size). > > Thanks for the x86 lesson with this. 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