2010/3/30 Garrett D'Amore <garrett.dam...@oracle.com>:
> On 03/29/10 07:14 PM, ольга крыжановская wrote:
>>
>> That may be true for Opensolaris on SPARC and i386 but at least the
>> community tries to extend scope the scope beyond servers with 16TB
>> memory. The system should scale on all platforms from very small
>> embedded hardware (e.g. ARM with 16MB of memory) up to superservers
>> with 1PB of memory. This has been at least a goal of the ksh93 project
>> which tries hard to provide an efficient, small, capable and adaptive
>> core of POSIX utilities which scales from the smallest to the largest
>> environments.
>>
>> IMO the default for PIPE_BUF should be a kernel tunable and I agree
>> (out of feature parity with FreeBSD) that ulimit -p should be a
>> writable limit to accommodate easy and portable performance tuning.
>>
>> Garrett, care to sponsor an ARC case for ulimit -p?
>>
>
> I need to think about this. I'd like to understand what the original
> objections were to it. I suspect the concern was about breaking userland
> applications which may have hardcoded PIPE_BUF into binaries.
>
> Does POSIX have any advice here?
I don't know. But I agree with the analysis from Irek which said that:
> The pipe users expect to do atomic writes and reads in chunks of
> PIPE_BUF bytes. Increasing the pipe buffer to n*PIPE_BUF (e.g. 5120,
> 10240, 20480, 40960, ...) is safe.
But I think ulimit -p should not be restricted to certain buffer
sizes, it should be the script author to pick a safe value.
If we use a global kernel tunable for setting the default PIPE_BUF it
could spew a warning to /var/adm/messages if the size is not a
multiple of 5120.
Chris
--
^---^
(@)v(@) Chris Pickett
| / IT consultant
===m==m=== pkch...@users.sourceforge.net
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
