Date: Wed, 13 May 2015 08:34:33 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Ian Lepore <ian@freebsd.org> Cc: Hans Petter Selasky <hps@selasky.org>, David Chisnall <theraven@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Baptiste Daroussin <bapt@freebsd.org>, "current@freebsd.org" <current@freebsd.org> Subject: Re: Increase BUFSIZ to 8192 Message-ID: <CAJ-VmonL9mT4JLqfSefKYiwv5-ecLkx9RZ5=kXt__%2Bs9iO4%2B9Q@mail.gmail.com> In-Reply-To: <1431528249.1221.15.camel@freebsd.org> References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <A1224018-7540-4C76-91EF-AEA2655E49A8@FreeBSD.org> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[snip] 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. So, if it's underlying block size, maybe BUFSIZ isn't the thing to tweak, but based on disk io buffer size. If it's filling L1 or L2 cache with useful work, maybe auto-tune it based on that. If it's hiding interrupt latency over USB, then that should be addressed. etc, etc. Please don't take this as bikeshedding, I'd really like to see some "this is why it's faster" analysis rather than just numbers thrown around. -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonL9mT4JLqfSefKYiwv5-ecLkx9RZ5=kXt__%2Bs9iO4%2B9Q>