From owner-freebsd-net@FreeBSD.ORG Fri Sep 6 20:09:26 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 1E24A4C2; Fri, 6 Sep 2013 20:09:26 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 769C520FB; Fri, 6 Sep 2013 20:09:25 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id d49so1849759eek.34 for ; Fri, 06 Sep 2013 13:09:23 -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=crZEcQYlb4awP9TRtF5DMdpwHBh4McNx3osxAjmwwxk=; b=NJwSXUqAYjnZoRucad8yVUYSaiLa4If1QVpd1FJcKX5SmCY6qCi6oacvs7cp1Nav0V XyhV2AIMVDzdT2yIXaH8oQpBLN/W0rvcvu0rFcNxV8TCDvT9jD7dTcEWkGW7ukU3dkaH mfHjEda7g79zOs6zojf3ao8J+iQDAIrQexEdAkNiCWi3ibA3r6PenOLfrkySzR/uckwQ 4WLW3xTBkg2rgVw5iyqyDLdIexfoG3gK81PLSaStI7bfyM+cRlhnflQU+QhE+JGDdfV1 RC75/SFfL7By/hD31yTwWTMW7w6WVxLt0fXR6sdqDP63lEBKradVAQ7akSQrA3rwLRPF vYIg== MIME-Version: 1.0 X-Received: by 10.15.36.9 with SMTP id h9mr6840621eev.30.1378498163867; Fri, 06 Sep 2013 13:09:23 -0700 (PDT) Received: by 10.14.105.137 with HTTP; Fri, 6 Sep 2013 13:09:23 -0700 (PDT) In-Reply-To: <522A2F2E.8080808@freebsd.org> References: <522A2993.6020206@mu.org> <522A2F2E.8080808@freebsd.org> Date: Fri, 6 Sep 2013 13:09:23 -0700 Message-ID: Subject: Re: mbuf autotuning changes From: hiren panchasara To: Alfred Perlstein 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 20:09:26 -0000 On Fri, Sep 6, 2013 at 12:38 PM, Alfred Perlstein wrote: > 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@**fre** >>>> ebsd.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. I guess its verbose enough in kern_mbuf.c I just had to *actually* read getenv_quad() to know that its not setting the variable to 0, it was just the return value. We can probably do: [hirenp@wholecorner ~/commit_head/sys/kern]$ svn diff Index: kern_environment.c =================================================================== --- kern_environment.c (revision 255320) +++ kern_environment.c (working copy) @@ -530,7 +530,8 @@ } /* - * Return a quad_t value from an environment variable. + * Return a quad_t value from an environment variable inside "data". + * If the environment variable is not set, "data" will be unchanged. */ int getenv_quad(const char *name, quad_t *data) cheers, Hiren