svn commit: r243631 - in head/sys: kern sys

[Andre Oppermann]

On 18.12.2012 06:40, Oleksandr Tymoshenko wrote:
>
> On 2012-12-08, at 1:21 PM, Alan Cox <alc at rice.edu> wrote:
>
>> On 12/08/2012 14:32, Andre Oppermann wrote:
>>>>
>
> .. skipped ..
>
>>>
>>> The trouble seems to come from NSFBUFS which is (512 + maxusers * 16)
>>> resulting in a kernel map of (512 + 400 * 16) * PAGE_SIZE = 27MB.  This
>>> seem to be pushing it with the smaller ARM kmap layout.
>>>
>>> Does it boot and run when you set the tunable kern.ipc.nsfbufs=3500?
>>>
>>> ARM does have a direct map mode as well which doesn't require the
>>> allocation
>>> of sfbufs.  I'm not sure which other problems that approach has.
>>>
>>
>>
>> Only a few (3?) platforms use it.  It reduces the size of the user
>> address space, and translation between physical addresses and direct map
>> addresses is not computationally trivial as it is on other
>> architectures, e.g., amd64, ia64.  However, it does try to use large
>> page mappings.
>>
>>
>>> Hopefully alc@ (added to cc) can answer that and also why the kmap of
>>> 27MB
>>> manages to wrench the ARM kernel.
>>>
>>
>>
>> Arm does not define caps on either the buffer map size (param.h) or the
>> kmem map size (vmparam.h).  It would probably make sense to copy these
>> definitions from i386.
>
>
> Adding caps didn't help. I did some digging and found out that although address range
> 0xc0000000 .. 0xffffffff is indeed valid for ARM in general actual KVA space varies for
> each specific hardware platform. This "real" KVA is defined by <virtual_avail, virtual_end>
> pair and ifI use them instead of <VM_MIN_KERNEL_ADDRESS, VM_MAX_KERNEL_ADDRESS>
> in init_param2 function my pandaboard successfully boots. Since former pair is used for defining
> kernel_map boundaries I believe it should be used for auto tuning as well.

OK.  Thank you for debugging this on ARM.  I'll adjust the auto-tuning
code accordingly.

-- 
Andre