From owner-freebsd-current@FreeBSD.ORG Thu May 14 07:22:00 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B0ADAF3; Thu, 14 May 2015 07:22:00 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B3E40182E; Thu, 14 May 2015 07:21:59 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t4E7LvMx061941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2015 00:21:57 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t4E7Lu1K061940; Thu, 14 May 2015 00:21:56 -0700 (PDT) (envelope-from jmg) Date: Thu, 14 May 2015 00:21:56 -0700 From: John-Mark Gurney To: Ian Lepore Cc: Adrian Chadd , Hans Petter Selasky , David Chisnall , Poul-Henning Kamp , Baptiste Daroussin , "current@freebsd.org" Subject: Re: Increase BUFSIZ to 8192 Message-ID: <20150514072155.GT37063@funkthat.com> References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org> <20150513181347.GM37063@funkthat.com> <1431542835.1221.30.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1431542835.1221.30.camel@freebsd.org> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Thu, 14 May 2015 00:21:57 -0700 (PDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 07:22:00 -0000 Ian Lepore wrote this message on Wed, May 13, 2015 at 12:47 -0600: > On Wed, 2015-05-13 at 11:13 -0700, John-Mark Gurney wrote: > > Adrian Chadd wrote this message on Wed, May 13, 2015 at 08:34 -0700: > > > The reason I ask about "why is it faster?" is because for embedded-y > > > things with low RAM we may not want that to happen due to memory > > > constraints. However, we may actually want to do some form of > > > autotuning on some platforms. > > > > If you're already running a program, the difference between 1k and > > 8k isn't significant... I'll give you 64k can be significant for > > embedded-y platforms... But this goes back to the, we need a global > > knob saying I want low memory usage, and I am willing to pay for it > > in performance... > > It is NOT just a difference of 1K vs 8K. It's that much times however > many BUFSIZ-sized things a program has allocated at once. It's where > they are allocated. As I've already pointed out, BUFSIZ appears in the > base code over 2000 times. Where is the analysis of the impact an 8x > change is going to have on all those uses? Since you apprently missed my original reply, I said that we shouldn't abuse BUFSIZ for this work, and that it should be changed in mdXhl.c... I agree that changing this size to effect all the other files is ill advised and should not be done... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."