From owner-svn-src-head@FreeBSD.ORG Wed Nov 28 23:16:01 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92A2874D for ; Wed, 28 Nov 2012 23:16:01 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id E507B8FC15 for ; Wed, 28 Nov 2012 23:16:00 +0000 (UTC) Received: (qmail 46685 invoked from network); 29 Nov 2012 00:47:23 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Nov 2012 00:47:23 -0000 Message-ID: <50B69B22.80706@freebsd.org> Date: Thu, 29 Nov 2012 00:15:46 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Bruce Evans Subject: Re: svn commit: r243631 - in head/sys: kern sys References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50B64BE8.3040708@rice.edu> <20121129072617.T1123@besplex.bde.org> In-Reply-To: <20121129072617.T1123@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Alan Cox X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 23:16:01 -0000 On 28.11.2012 22:45, Bruce Evans wrote: > On Wed, 28 Nov 2012, Alan Cox wrote: > >> I'm pretty sure that the "realmem" calculation is going to overflow on >> i386/PAE, where the number of bytes of physical memory is greater than >> the type long can represent. > > It overflows on i386 even without PAE, where the number of bytes of > physical memory is greater than the type long can represent (2GB). This is the usual case for new > hardware. Please have a look at the attached patch. Is quad_t the appropriate type to use? If not, which is the right one? > I think it changes the defaults for machines with small amounts of > memory (say 32MB) in dangerous ways. > > Reserving half of kva for mbufs is network-centric. I reserve more > than half of kva for the buffer cache in some configurations > (VM_BCACHE_SIZE_MAX defaults too 200 MB, but I use 512 MB), and in the > old scheme where the default for mbufs was under-sized, this may even > have fitted without separate tuning for mbufs. Please note that NO *reservations* are made for mbufs. It's only *limits* that are enforced. For example stand-alone mbufs were not limited at all previously and could completely exhaust all available kernel memory. > The code has lots of style bugs. Thank you for your detailed input. I'll handle that after the "long" overflow issue is solved. -- Andre Index: kern/subr_param.c =================================================================== --- kern/subr_param.c (revision 243631) +++ kern/subr_param.c (working copy) @@ -271,7 +271,7 @@ void init_param2(long physpages) { - long realmem; + quad_t realmem; /* Base parameters */ maxusers = MAXUSERS; @@ -332,10 +332,10 @@ * available kernel memory (physical or kmem). * At most it can be 3/4 of available kernel memory. */ - realmem = lmin(physpages * PAGE_SIZE, + realmem = qmin(physpages * PAGE_SIZE, VM_MAX_KERNEL_ADDRESS - VM_MIN_KERNEL_ADDRESS); maxmbufmem = realmem / 2; - TUNABLE_LONG_FETCH("kern.maxmbufmem", &maxmbufmem); + TUNABLE_QUAD_FETCH("kern.maxmbufmem", &maxmbufmem); if (maxmbufmem > (realmem / 4) * 3) maxmbufmem = (realmem / 4) * 3; Index: sys/mbuf.h =================================================================== --- sys/mbuf.h (revision 243631) +++ sys/mbuf.h (working copy) @@ -395,7 +395,7 @@ * * The rest of it is defined in kern/kern_mbuf.c */ -extern long maxmbufmem; +extern quad_t maxmbufmem; extern uma_zone_t zone_mbuf; extern uma_zone_t zone_clust; extern uma_zone_t zone_pack;