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?
Olga
On Tue, Mar 30, 2010 at 3:57 AM, <johan...@opensolaris.org> wrote:
> On Tue, Mar 30, 2010 at 02:47:14AM +0200, Chris Pickett wrote:
>> Re port to Solaris: No, I will not port this to Solaris. I've been
>> told that making ulimit's -p a tunable will not pass ARC review and I
>> am not going to write patches just to throw them away because ARC
>> doesn't like it.
>
> That said, it would be trivial to write a patch to change PIPE_BUF to
> 10240 on Solaris. I don't believe that Oracle ships a machine with less than
> 1g of RAM today. That gets you out of the 'ulimit -p' business, and
> if I understand correctly, it's a handy performance win too. (I would
> be interested in seeing your benchmark numbers on this, though).
>
> -j
> _______________________________________________
> perf-discuss mailing list
> perf-discuss@opensolaris.org
>
--
, _ _ ,
{ \/`o;====- Olga Kryzhanovska -====;o`\/ }
.----'-/`-/ olga.kryzhanov...@gmail.com \-`\-'----.
`'-..-| / Solaris/BSD//C/C++ programmer \ |-..-'`
/\/\ /\/\
`--` `--`
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
