From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 13:11:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8910C16A4D1 for ; Mon, 19 Jan 2004 13:11:39 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 920E443D49 for ; Mon, 19 Jan 2004 13:11:37 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i0JLBY82004061; Mon, 19 Jan 2004 13:11:34 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i0JLBYVk004060; Mon, 19 Jan 2004 13:11:34 -0800 (PST) (envelope-from dillon) Date: Mon, 19 Jan 2004 13:11:34 -0800 (PST) From: Matthew Dillon Message-Id: <200401192111.i0JLBYVk004060@apollo.backplane.com> To: Poul-Henning Kamp References: <98336.1074543216@critter.freebsd.dk> cc: current@freebsd.org Subject: Re: Is BUFSIZ too small ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 19 Jan 2004 21:11:39 -0000 :I noticed that we still have BUFSIZ in stdio.h defined to only 1024, :and wonder if that should be increased these days. : :Is there anybody who could devise and run some benchmarks to find :out what effect it would have to increase it to for instance 4096 ? : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :phk@FreeBSD.ORG | TCP/IP since RFC 956 STDIO uses st.st_blksize sized I/O buffers by default, which will be either 8K or 16K on most machines. Very few programs use BUFSIZ for the actual I/O ops but libc seems to use it for stack-declared buffers (e.g. like in /usr/src/lib/libc/net/getservent.c, net/name6.c, net/gethostnamadr.c, etc). vprintf uses it but I doubt that would impact performance.l Unbuffered FILE I/O (setvbuf SNBF) will cause writes to be broken down into BUFSIZ chunks... but who uses unbuffered I/O in that manner? Not very many programs I would wager. So, just at a guess, raising BUFSIZ could lead to unnecessary dirty page bloat in most programs and would otherwise not improve performance. It might be worth seeing what stdout's behavior is when the program output runs through a pipe. If it is dropping down to BUFSIZ for pipes it might be worth fixing __swhatbuf() in stdio/makebuf.c, but I still wouldn't bother with BUFSIZ. -Matt Matthew Dillon