From owner-freebsd-stable@FreeBSD.ORG Thu Dec 29 16:24:25 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F081106568A for ; Thu, 29 Dec 2011 16:24:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 032108FC13 for ; Thu, 29 Dec 2011 16:24:25 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id AD35446B46; Thu, 29 Dec 2011 11:24:24 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3E87EB96B; Thu, 29 Dec 2011 11:24:24 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 29 Dec 2011 11:08:32 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4EF3B790.5050509@sgi.com> <4EF50882.9080609@sgi.com> <20111224002044.GA30339@icarus.home.lan> In-Reply-To: <20111224002044.GA30339@icarus.home.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112291108.33075.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Dec 2011 11:24:24 -0500 (EST) Cc: Eric Richards , Larry Fenske , Charlie Martin , "Peter W. Morreale" , Jeremy Chadwick Subject: Re: PRINTF_BUFR_SIZE=4096? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 16:24:25 -0000 On Friday, December 23, 2011 7:20:44 pm Jeremy Chadwick wrote: > On Fri, Dec 23, 2011 at 04:02:26PM -0700, Charlie Martin wrote: > The value 256 is something *I personally* chose, because 128 was simply > not improving things "enough" on our systems. 256 made a bigger > difference. The reason it still remains as 128 in the stock kernel > configs is due to the issue I mentioned in my previous post, re: > developers having justified concerns over the implications of increasing > this value too high. > > I want readers of this thread to understand something: my previous > paragraph should not elude to "the higher the value, the better off you > are". I have not actually *looked* at the code to see how it works. I > tend to trust folks who know more about the implications (especially in > kernel space) of large static buffers, but even in userland I understand > the difference and implications of doing char buf[65536]; rather than > char *buf = calloc(1, 65536);. Actually, the higher the value, the worse off you are in other ways. I've had to turn off PRINTF_BUFR_SIZE completely at work. The problem is that PRINTF_BUFR_SIZE uses a cnputs() routine that disables interrupts for the _entire_ duration of outputting the string. Previously with printf() using a loop around cnputc() interrupts were only disabled for each character and re-enabled in the loop. This capped the interrupt latency at one-character. Now you can get up to 128 (or 256) times the interrupt latency hit. Granted, that may not matter for many (most?) workloads, but if you are doing routing with high pps it may very well matter. At work the problem we ran into was single line printfs stalling clock interrupts. I have not figured out why syscons cnputc() can take so long, but it appears to be rather slow. -- John Baldwin