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

[Bruce Evans]

On Mon, 3 Dec 2018, Justin Hibbits wrote:

> On Wed, 28 Nov 2018 16:31:33 +1100 (EST)
> Bruce Evans <brde at optusnet.com.au> 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