From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 21 19:58:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D47EC106564A; Fri, 21 Jan 2011 19:58:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B6AEE8FC08; Fri, 21 Jan 2011 19:58:46 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p0LJwfNj023955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 21:58:41 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p0LJwfxV055734; Fri, 21 Jan 2011 21:58:41 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p0LJwf8c055733; Fri, 21 Jan 2011 21:58:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 21 Jan 2011 21:58:41 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20110121195841.GA2518@deviant.kiev.zoral.com.ua> References: <201101211244.13830.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0w3sVzSwLDVzzp/e" Content-Disposition: inline In-Reply-To: <201101211244.13830.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, Sergey Kandaurov Subject: Re: [rfc] allow to boot with >= 256GB physmem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 19:58:48 -0000 --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--