From owner-freebsd-net@FreeBSD.ORG Sun Sep 8 07:20:03 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 21542ED9 for ; Sun, 8 Sep 2013 07:20:03 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C37D2E57 for ; Sun, 8 Sep 2013 07:20:02 +0000 (UTC) Received: (qmail 59840 invoked from network); 8 Sep 2013 07:59:54 -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 ; 8 Sep 2013 07:59:54 -0000 Message-ID: <522C2516.9030406@freebsd.org> Date: Sun, 08 Sep 2013 09:19:50 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ian Lepore Subject: Re: mbuf autotuning effect References: <9CBFAD35-D651-4E28-BEBB-DC3717F38567@bsdimp.com> <1378583762.1111.512.camel@revolution.hippie.lan> In-Reply-To: <1378583762.1111.512.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, hiren panchasara , "freebsd-mips@freebsd.org" , Warner Losh 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: Sun, 08 Sep 2013 07:20:03 -0000 On 07.09.2013 21:56, Ian Lepore wrote: > On Sat, 2013-09-07 at 12:21 -0700, hiren panchasara wrote: >> On Sep 6, 2013 8:26 PM, "Warner Losh" wrote: >>> >>> >>> On Sep 6, 2013, at 7:11 PM, Adrian Chadd wrote: >>> >>>> Yeah, why is VM_KMEM_SIZE only 12mbyte for MIPS? That's a little >> low >> for a >>>> platform that has a direct map that's slightly larger than 12mb :) >>>> >>>> Warner? Juli? >>> >>> All architectures have it at 12MB, except sparc64 where it is 16MB. >> This >> can be changed with the options VM_KMEM_SIZE=xxxxx in the config file. >> >> Right. Does that mean for any platform, if we do not have nmbclusters >> pre-set in kmeminit() than we will always have pretty low value of >> vm_kmem_size. And because of that, if maxmbufmem is not pre-set (via >> loader.conf) inside tunable_mbinit() , we will have very low value for >> maxmbufmem too. >> >> I hope (partially believe) that my understanding is not entirely >> correct. >> Because if its correct, we arw depending on loader.conf instead of >> actually >> auto tuning. >> > I think the part of this that strikes me as strange is calling 20% of > physical memory used for network buffers a "very low value". It seems > outrageously high to me. I'd be pissed if that much memory got wasted > on network buffers on one of our $work platforms with so little memory. This memory is NOT allocated to the mbuf system. It is just the upper *limit* how far it can go when the demand is there. > So the fact that you think it's crazy-low and I think it's crazy-high > may be a sign that it's auto-tuned to a reasonable compromise, and in > both our cases the right fix would be to use the available knobs to tune > things for our particular uses. Yes. The autotuning network memory *limit* is a compromise that allows big beefy network servers work well right out of the box while not killing small ones. Lets say it covers > 90% of our actual users and use cases. If you have special requirements then you may have to tune these values, but if you known exactly what your system is going to do, then chances are you're tuning various other parameters anyways. -- Andre