[rfc] allow to boot with >= 256GB physmem

[Sergey Kandaurov]

On 21 January 2011 20:44, John Baldwin <jhb at freebsd.org> wrote:
> On Friday, January 21, 2011 11:09:10 am Sergey Kandaurov wrote:
>> Hello.
>>
>> Some time ago I faced with a problem booting with 400GB physmem.
>> The problem is that vm.max_proc_mmap type overflows with
>> such high value, and that results in a broken mmap() syscall.
>> The max_proc_mmap value is a signed int and roughly calculated
>> at vmmapentry_rsrc_init() as u_long vm_kmem_size quotient:
>> vm_kmem_size / sizeof(struct vm_map_entry) / 100.
>>
>> Although at the time it was introduced at svn r57263 the value
>> was quite low (f.e. the related commit log stands:
>> "The value defaults to around 9000 for a 128MB machine."),
>> the problem is observed on amd64 where KVA space after
>> r212784 is factually bound to the only physical memory size.
>>
>> With INT_MAX here is 0x7fffffff, and sizeof(struct vm_map_entry)
>> is 120, it's enough to have sligthly less than 256GB to be able
>> to reproduce the problem.
>>
>> I rewrote vmmapentry_rsrc_init() to set large enough limit for
>> max_proc_mmap just to protect from integer type overflow.
>> As it's also possible to live tune this value, I also added a
>> simple anti-shoot constraint to its sysctl handler.
>> I'm not sure though if it's worth to commit the second part.
>>
>> As this patch may cause some bikeshedding,
>> I'd like to hear your comments before I will commit it.
>>
>> http://plukky.net/~pluknet/patches/max_proc_mmap.diff
>
> Is there any reason we can't just make this variable and sysctl a long?
>

That was my initial thought, but now I'm afraid this can result
in 32bit vs 64bit comparison issue below in code.

-- 
wbr,
pluknet