Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Jan 2011 21:58:41 +0200
From:      Kostik Belousov <kostikbel@gmail.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-hackers@freebsd.org, Sergey Kandaurov <pluknet@gmail.com>
Subject:   Re: [rfc] allow to boot with >= 256GB physmem
Message-ID:  <20110121195841.GA2518@deviant.kiev.zoral.com.ua>
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

--0w3sVzSwLDVzzp/e
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 21, 2011 at 12:44:13PM -0500, John Baldwin wrote:
> On Friday, January 21, 2011 11:09:10 am Sergey Kandaurov wrote:
> > Hello.
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > As this patch may cause some bikeshedding,
> > I'd like to hear your comments before I will commit it.
> >=20
> > http://plukky.net/~pluknet/patches/max_proc_mmap.diff
>=20
> Is there any reason we can't just make this variable and sysctl a long?
I do not think we ever need 2G vm map entries in the single address space.

--0w3sVzSwLDVzzp/e
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iEYEARECAAYFAk055XEACgkQC3+MBN1Mb4i18ACfRPoNewWV614iaSp+JkTffK5z
CcMAoL2FLbg/0myY890cXtmiJFx0DUfQ
=8A6Q
-----END PGP SIGNATURE-----

--0w3sVzSwLDVzzp/e--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110121195841.GA2518>