Date: Sun, 24 Feb 2013 21:11:15 -0600 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Alan Cox <alc@rice.edu> Cc: Kostik Belousov <kostikbel@gmail.com>, ppc@freebsd.org, grehan@freebsd.org Subject: Re: kernel address space and auto-sizing Message-ID: <512AD653.2070603@freebsd.org> In-Reply-To: <512AD5AD.3090303@rice.edu> References: <512AAB65.1000402@rice.edu> <512AB347.4030603@freebsd.org> <512AD5AD.3090303@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?512AD653.2070603>