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

[Andre Oppermann]

On 07.01.2013 20:32, Alan Cox wrote:
> On 01/07/2013 12:47, Oleksandr Tymoshenko wrote:
>> On 12/27/2012 6:46 PM, Oleksandr Tymoshenko wrote:
>>> On 12/18/2012 1:59 AM, Alan Cox wrote:
>>>> On 12/17/2012 23: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.
>>>>
>>>> That makes sense.  However, "virtual_avail" isn't the start of the
>>>> kernel address space.  The kernel map always starts at
>>>> VM_MIN_KERNEL_ADDRESS.  (See kmem_init().)  "virtual_avail" represents
>>>> the next unallocated virtual address in the kernel address space at an
>>>> early point in initialization.  "virtual_avail" and "virtual_end"
>>>> aren't
>>>> used after that, or outside the VM system.  Please use
>>>> vm_map_min(kernel_map) and vm_map_max(kernel_map) instead.
>>>
>>> I checked: kernel_map is not available (NULL) at this point.  So we
>>> can't use it to
>>> determine real KVA size. Closest thing we can get is
>>> virtual_avail/virtual_end pair.
>>>
>>> Andre, could you approve attached patch for commit or suggest better
>>> solution?
>>
>> Any update on this one? Can I proceed with commit?
>>
>
> Sorry, I've been away from my e-mail since the 30th, and I'm now in the
> process of getting caught up.  Give me a day or so to look at this.

Ditto.

-- 
Andre