svn commit: r216016 - head/sys/sparc64/include

[Alan Cox]

mdf at FreeBSD.org wrote:
> On Tue, Dec 7, 2010 at 5:41 AM, Marius Strobl <marius at alchemy.franken.de> wrote:
>   
>> On Mon, Dec 06, 2010 at 02:30:01PM -0800, mdf at FreeBSD.org wrote:
>>     
>>> On Mon, Dec 6, 2010 at 2:07 PM, Marius Strobl <marius at alchemy.franken.de> wrote:
>>> [lots of snip]
>>>
>>>       
>>>> With that one the kernel now survies memguard_init() but then panics
>>>> right afterwards when kmeminit() calls kmem_suballoc():
>>>> KDB: debugger backends: ddb
>>>> KDB: current backend: ddb
>>>> Copyright (c) 1992-2010 The FreeBSD Project.
>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>>> ? ? ? ?The Regents of the University of California. All rights reserved.
>>>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>>>> FreeBSD 9.0-CURRENT #18 r215249:216120M: Mon Dec ?6 13:27:57 CET 2010
>>>> ? ?marius at v20z.zeist.de:/home/marius/co/build/head2/sparc64.sparc64/usr/home/m4
>>>> WARNING: WITNESS option enabled, expect reduced performance.
>>>> panic: kmem_suballoc: bad status return of 3
>>>>         
>>> [more snip]
>>>
>>> Shooting in the dark a little...
>>>
>>> The bad status of 3 is presumably KERN_NO_SPACE because we attempted
>>> to allocate too much space from the kernel_map.  What are the actual
>>> values of vm_kmem_size, kernel_map->min_offset, kernel_map->max_offset
>>> at panic time?
>>>       
>> vm_kmem_size=5610405888 min_offset=3221225472 max_offset=13958643712
>> This is on a US3i machine with 16GB RAM.
>>     
>
> So kernel_map is from 0xC000_0000 to 0x3_4000_0000, or 0x2_8000_0000
> bytes large.  Double the vm_kmem_size is 0x2_9CD0_0000, which is why
> this is failing.
>
> This to me says that, for the moment, you need the
> VM_MAX_KERNEL_ADDRESS define so that memguard does not take up too
> much virtual space; at the moment this hardware is somewhat
> constrained on virtual space.
>   

Yes, I had thought that sparc64 had a much larger kernel address space.  
Marius, I would suggest that you revert back to Max's original commit 
that caps the kmem_map at 3/5 of the kernel address space.  Right now, 
you are allowing the kmem_map to consume the entire kernel address 
space, and given the relatively modest size of the kernel address space, 
a machine with more physical memory may try to create a kmem_map that 
leaves no space for the buffer cache, pipes, thread stacks, etc.

Alan