Date: Fri, 21 Jan 2011 21:01:11 +0300 From: Sergey Kandaurov <pluknet@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: [rfc] allow to boot with >= 256GB physmem Message-ID: <AANLkTimctYrvnMej=wRou87hZSaMA_CmomQc29vn5eex@mail.gmail.com> In-Reply-To: <201101211244.13830.jhb@freebsd.org> References: <AANLkTikt5=2L0rHyGbsjvG8eV6Ve4JkRM_pcyNiAsPu8@mail.gmail.com> <201101211244.13830.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 January 2011 20:44, John Baldwin <jhb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimctYrvnMej=wRou87hZSaMA_CmomQc29vn5eex>