From owner-freebsd-net@FreeBSD.ORG Fri Sep 6 19:36:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DBEBAFB7; Fri, 6 Sep 2013 19:36:49 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D2F72B59; Fri, 6 Sep 2013 19:36:49 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id e53so1860278eek.27 for ; Fri, 06 Sep 2013 12:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Aiqa3XzzMjqU2TGFwKwNON9nZbDdr3l75i0xARuFGM8=; b=R4/7HmZe9Nu0RPQnrPo+b5KDoKQrVo4Dx+f6wydfNfvx0jGKhFcfR60yi0gsKYzcll tmhmt8yI7a/sgR2rhJU91ucyvFlfAzbYV9T+Ycdp5xNXoY9AoXr7Wxw0zZwbCZ7mEZ+c GjhRVFgPvX8Hl8o2qg7C2/8tvKV36ub868pbJcInyDzSAYsynUGsrOEiYQV7l9js+y2D Uzbseo3HCRY5soIee/i36l3/8YwUn3mP0bv1aEz92B65hg3uVDZCbf6p3TApAehyFDF4 Ad/ca4GouKTYiNLuNtaNRWTn/xSmQeaws8iNPhotR3xVUJUwMhp1kDWg+ok04EGHgRQW 7c6g== MIME-Version: 1.0 X-Received: by 10.14.177.199 with SMTP id d47mr6515120eem.14.1378496207559; Fri, 06 Sep 2013 12:36:47 -0700 (PDT) Received: by 10.14.105.137 with HTTP; Fri, 6 Sep 2013 12:36:47 -0700 (PDT) In-Reply-To: <522A2993.6020206@mu.org> References: <522A2993.6020206@mu.org> Date: Fri, 6 Sep 2013 12:36:47 -0700 Message-ID: Subject: Re: mbuf autotuning changes From: hiren panchasara To: Alfred Perlstein , Navdeep Parhar Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" 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:36:49 -0000 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. Thanks again. Hiren