From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 21 18:01:12 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 6D0E3106566C; Fri, 21 Jan 2011 18:01:12 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 09BAC8FC0C; Fri, 21 Jan 2011 18:01:11 +0000 (UTC) Received: by qwj9 with SMTP id 9so2010106qwj.13 for ; Fri, 21 Jan 2011 10:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0AlfnCxBKILan4B3Zc0vgiF9qdEvtcu4uF+MHkaG7Zo=; b=SxlDCuNsXXNugWxdDW7QEqZi7ZqgybzhfMHTX70S38pAGDS8n5quXeOigfZqhb4jJC DDmFSfRfhYBIjniyRTIWVPWVbGLq0FQiPAXH4KM3rtQD/1lEh36+KaLCnIZWmrONSAoB OLi4jeP1wGWg297qDGGzXWmCm42pEXhACxdhM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pOEipGzxC2fCQcLt9nAWe6js2U5y5WG93qDPLYdBYiE82vIilIn46n7C7FSvgXX+JO FAWlveAl0SailLPHIdycTIzT33G1huPzPWt7EGUrr1FhQaNpJN3KzJLZHlasf2dPyb0n gsz+sTf1eT4Ni648laXI5DOJ/E9lwyTROk+pQ= MIME-Version: 1.0 Received: by 10.229.83.198 with SMTP id g6mr793174qcl.157.1295632871155; Fri, 21 Jan 2011 10:01:11 -0800 (PST) Received: by 10.229.102.87 with HTTP; Fri, 21 Jan 2011 10:01:11 -0800 (PST) In-Reply-To: <201101211244.13830.jhb@freebsd.org> References: <201101211244.13830.jhb@freebsd.org> Date: Fri, 21 Jan 2011 21:01:11 +0300 Message-ID: From: Sergey Kandaurov To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org 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 18:01:12 -0000 On 21 January 2011 20:44, John Baldwin 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