Eric C. Saxe wrote:

Hey look at that. My previous message has been robbed of line breaks and the first part of this thread has gone missing. Looks like the html I embedded really confused things. Here's a more readable version of my last message. I'll let Derek know that this thread needs to be fixed...


OK, I just deleted the whole thread by accident (loudly kicking self).

However it looks the thread split for some reason, as compared to how it looks in the mail client. I will have to figure out how to restore it tommorrow and address the HTML problem.

Derek


-Eric

On 8/8/05, Ben Cooper <[EMAIL PROTECTED]> wrote:

I thought it would be interesting to get these
running on Mac OS X/
PPC since there's no Darwin makefile included in the
release.


Hey, this is really great.

So the tests compiled and ran, but as soon as I got
to the fork I got
resource temporarily unavailable messages (as in the
snippet below).
Now I would've expected this to be because of the
low(ish) maxproc
and maxprocperuid limit in OS X, so I bumped them up
to

kern.maxproc=2048
kern.maxprocperuid=512

with still no luck. Can someone tell me what this
setting is in
Solaris? I should post this on the Darwin mailing
lists but I thought
I'd share my experience with you guys first.


param_init() and param_calc() figure the global and per user limit on the max number of processes. It depends on a few things like the max number of users, amount of memory, etc.

On an x86 test machine i'm seeing:
v_proc = 0x207a
v_maxup = 0x2075

0x207a=D

8314

0x2075=D

8309

So around 8300 for both. The "c_" tests deal with some number of
processes/threads that are handing locks around in a ring. The "_10"
tests should be creating 10 processes, the "_200" test should be
creating 200, etc...so it's interesting that you're hitting what seems
like should be a limit of 512 when the test is creating at most 200
processes....

I could see this happening if libMicro wasen't waiting for the
processes from one test to terminate before starting the new test, or
if there was some delay in the OS between the time a process exited
and the time that it's resources are returned to the system...
This message posted from opensolaris.org
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org




--
Derek Cicero
Program Manager
Solaris Kernel Group, Software Division
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org

Reply via email to