On Thu 11 Aug 2005 at 11:22AM, Eric C. Saxe wrote:
> Ben Cooper wrote:
>
> > Interestingly when I ran the cascade_flock 200 test
> > manually I got
> > the resource temporarily unavailable fork error
> > straight away, so I
> > don't think it's libMicro not waiting for the
> > processes of previous
> > tests to run. When I tried putting the kern.maxproc
> > and macprocperuid
> > as high as it would go (2068 seemed to be it's hard
> > limit), the same
> > behaviour occurred.
>
> It might be that OS X is enforcing some limit for you based on
> factors like the size of the system, amount of memory, etc similar
> to the way Solaris does. If there's a way you can look at the current
> limit on the live system (by examing the value of the proper kernel variable)
> that might be interesting (hey, maybe you could override it :)).
> Alternatively, you could probably whip up a little test that forks() until
> failure,
> reporting how many process you were able to sucessfully create before hitting
> EAGAIN.
> This message posted from opensolaris.org
This might sound dumb, but are we sure that processes are the resource
which is temporarily unavailable?
Can we get a trace using whatever the equivalent of truss is?
-dp
--
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
_______________________________________________
perf-discuss mailing list
[email protected]