From owner-freebsd-net@FreeBSD.ORG Fri Sep 6 19:38:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ECFC3155 for ; Fri, 6 Sep 2013 19:38:23 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D9F562B97 for ; Fri, 6 Sep 2013 19:38:23 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 3CAFB1A3E27 for ; Fri, 6 Sep 2013 12:38:23 -0700 (PDT) Message-ID: <522A2F2E.8080808@freebsd.org> Date: Fri, 06 Sep 2013 12:38:22 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: mbuf autotuning changes References: <522A2993.6020206@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 19:38:24 -0000 On 9/6/13 12:36 PM, hiren panchasara wrote: > On Fri, Sep 6, 2013 at 12:14 PM, Alfred Perlstein wrote: > >> On 9/6/13 12:10 PM, hiren panchasara wrote: >> >>> tunable_mbinit() in kern_mbuf.c looks like this: >>> >>> 119 /* >>> 120 * The default limit for all mbuf related memory is 1/2 of all >>> 121 * available kernel memory (physical or kmem). >>> 122 * At most it can be 3/4 of available kernel memory. >>> 123 */ >>> 124 realmem = qmin((quad_t)physmem * PAGE_SIZE, >>> 125 vm_map_max(kmem_map) - vm_map_min(kmem_map)); >>> 126 maxmbufmem = realmem / 2; >>> 127 TUNABLE_QUAD_FETCH("kern.ipc.**maxmbufmem", &maxmbufmem); >>> 128 if (maxmbufmem > realmem / 4 * 3) >>> 129 maxmbufmem = realmem / 4 * 3; >>> >>> If I am reading the code correctly, we loose the value on line 126 when we >>> do FETCH on line 127. >>> >>> And after line 127, if we havent specified kern.ipc.maxmbufmem (in >>> loader.conf - I guess...), we set that value to 0. >>> >>> And because of that the if condition on line 128 is almost always false? >>> >>> What am I missing here? >>> >>> Thanks, >>> Hiren >>> ______________________________**_________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/**mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@**freebsd.org >>> " >>> >>> I think TUNABLE_*_FETCH will only write to the variable if it explicitly >> set. >> >> Meaning, unless the user actually sets a value in loader.conf then 127 is >> a no-op. >> > Thanks Navdeep and Alfred. > > Thats correct. Its not touching the var if its not set. > > I guess the other TUNABLE_INT_FETCHs later in the function checking for > variable ==0 confused me. i.e. nmbclusters. > > 131 TUNABLE_INT_FETCH("kern.ipc.nmbclusters", &nmbclusters); > 132 if (nmbclusters == 0) > 133 nmbclusters = maxmbufmem / MCLBYTES / 4; > > But those are global variable so here we are just checking if they are > explicitly set of not. If not, we will set them. > > For maxmbufmem, we will set it to 1/2 the realmem. and if user sets it > explicitly than we will make sure its not more than 3/4 of the realmem. Yes. It's somewhat confusing. I'm all for adding comments to this effect if you have the time and inclination. -Alfred