kernel address space and auto-sizing

[Nathan Whitehorn]

On 02/24/13 21:08, Alan Cox wrote:
> On 02/24/2013 18:41, Nathan Whitehorn wrote:
>> This is bringing back bad memories. Let me explain about
>> VM_MAX_SAFE_KERNEL_ADDRESS and mmu_oea64.c briefly.
>>
>> mmu_oea64 is the PMAP code for both PPC32 and PPC64 running on 64-bit
>> CPUs. Both AIM32 and AIM64 in general have a direct map. *However*,
>> 32-bit kernels running on 64-bit CPUs do *not* have a direct map.
>>
>> The memory layout when the kernel is booted is has the low 4 GB
>> organized into 16 256 MB segments. We keep all firmware mappings and try
>> to fit in a direct map. Segments 12 and 13 (0xc, 0xd) are guaranteed to
>> be free. OF allocates its own mappings at the end of segment 14 (0xe).
>> Everything else can't be touched. Without a direct map, having only 512
>> MB of KVA causes the kernel to regularly run out of VA space -- this was
>> crashing package building. To ameliorate that, I added the
>> MAX_SAFE_ADDRESS stuff and it then expands the KVA space from there into
>> segment 14 until it finds memory the firmware is actually using and ends
>> KVA there. I suspect this patch will cause a return to the crashing. Did
>> I miss something?
> 
> Let's ignore the patch for the moment.  Have you tried booting a 32-bit
> kernel on a 64-bit CPU since Andre's commit changing the mbuf
> auto-sizing?  As I mention below, 32-bit AIM defines VM_KMEM_SIZE to 12
> MB.  Before Andre's commit, we sized the kmem submap as VM_KMEM_SIZE
> plus sufficient space for the maximum number of mbuf clusters,
> nmbclusters.  Now, after Andre's change, nmbclusters hasn't been
> computed at the point the kmem submap is created.  Since 32-bit AIM
> doesn't define VM_KMEM_SIZE_SCALE, the kmem submap will be stuck at 12 MB.

No, only 64-bit kernels. I'll give it a try tomorrow unless someone else
beats me to it.
-Nathan