Date: Thu, 29 Dec 2011 11:08:32 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-stable@freebsd.org Cc: Eric Richards <erichards@sgi.com>, Larry Fenske <LFenske@sgi.com>, Charlie Martin <crmartin@sgi.com>, "Peter W. Morreale" <morreale@sgi.com>, Jeremy Chadwick <freebsd@jdc.parodius.com> Subject: Re: PRINTF_BUFR_SIZE=4096? Message-ID: <201112291108.33075.jhb@freebsd.org> In-Reply-To: <20111224002044.GA30339@icarus.home.lan> References: <4EF3B790.5050509@sgi.com> <4EF50882.9080609@sgi.com> <20111224002044.GA30339@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201112291108.33075.jhb>