On Sat, Mar 27, 2010 at 3:45 PM, <casper....@sun.com> wrote:
>
>>We've tried to increase the pipe buffer (not bufmod) on FreeBSD this
>>week. Besides some tricky implementation details the performance gains
>>in a pure 'copy data' benchmark are *astonishing*. Copy time for a
>>5140 buffer (from 512) goes down from 4 mins to 2 mins and for a 20480
>>buffer it goes down to 74 seconds (not a linear win but still
>>something to consider).
>>We'll post patches for FreeBSD next month.
>
> I think we should try to follow that example as long as we can get
> such performance gains. Do you have simple test code?
The test code were ksh93 and bash writing and reading large text
segments. ksh93 is a tick better suited because we can force the size
of writes via typeset -b but the results were better for both shells.
> What was "tricky"? Are there issues in applications?
No, the tricky parts were:
Implement ulimit -p
Find all locations in the kernel pipe code which use 512 (sometimes
disguised as #define, macro or other things).
Debug buffer overflows in the kernel.
Debug my little 5720 typo (having a terminal font which uses nearly
identical glyphs for 1 and 7 did *not* help).
Userland didn't notice the change except that many things now run
faster (gcc for example).
> (stdio creates buffers the size of whatever stat returns)
Yeah, ksh93 uses AST stdio for obvious reasons (performance, no weired
fd limits, ...) but uses the same solution to pick buffer sizes.
Chris
--
^---^
(@)v(@) Chris Pickett
| / IT consultant
===m==m=== pkch...@users.sourceforge.net
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
