It is also possible to run libMicro cases in just one process with the "-1" option (normally the test is run in child processes, with the parent waiting on the barrier for completion). The "-1" is incompatible with the "-P" option (you will get a warning), but is completely compatable with the "-T" option (since the mutexes remain process private).
Phil Ben Cooper wrote:
I got an excellent response on libMicro running on Mac OS X from the darwin-kernel list at lists.apple.com, and in the spirit of open communication I thought I'd share them here (he asked to be anonymous).Firstly, a little more background on my efforts to get the full suite to run on OS X. The following diff shows the elided tests such that I wouldn't get any unavailable resource errors or test hangs:$ diff Makefile.Darwin Makefile.Linux 42,50c42 < atomic \ < getcontext \ < setcontext \ < cascade_fcntl \ < cascade_flock \ < cascade_lockf \ < fork \ < exit \ < connection --- > atomic 53c45 < include ../Makefile.com.Darwin --- > include ../Makefile.comSo the cascase_* tests would give me the "resource temporarily unavailable" error, but I also has issues with fork, exit and the final connection test just seeming to hang.Regarding the fork and exit hangs> The exit and fork are hangs in their barrier operations assuming certain POSIX semantics that we don't > claim in our <unistd.h> settings, and which should have been conditionalized on those settings. They > have implementations for the Advanced Realtime Threads option, which neither we nor Linux support, > and they have an option for use of semop/semget/semctl in an mmaped space using (incorrectly) IPC_PRIVATE. > The correct implementation for our (or any IPC_PRIVATE) platform would use semop() by way of semid - > standards SystemV UNIX IPC, without the shared memory segment; if you have to use shared memory from > mmap() instead of shmget(), you'd need to use msync(), and the IPC_PRIVATE might still kill you. The only > use of msync() seems to be in the msync benchmark itself, which implies a misunderstanding or at least > some unjustifiable assumptions about the cache and memory coherency model required for UNIX systems.which does highlight the difficulty in writing a truly portable microbenchmark. I must admit I was concerned with replacing the reference to the realtime threads library to System on OS X (I was merely following some advice on getting it to compile). What is interesting is that apparently Linux doesn't support that library either, although I haven't tested these on Linux.And regarding the cascade_* tests my error wasn't able to be reproduced, but> I also got a CPU-eating infinite loop in cascade_fcntl(); it seems the code takes a very long time to run. > I think it also has a misunderstanding of the use of semop(), and it also seems to have an issue with > overall fcntl-based file lock semantics (perhaps it would have completed had I been more patient). As> far as I can tell, it never hits a hard limit there. >> I had no problems getting actual results from cascade_flock and cascade_lockf.This gets me nowhere with my error though. Perhaps it could be architecture related. I'd reproduced these errors on two G4 systems, and he had them running on a G5 and G3 system. It does seem unlikely that architecture could influence the amount of file locks the OS is willing to create though.I'd love to hear everyone's thoughts on this. Cheers, Ben On 12/08/2005, at 6:28 AM, Dan Price wrote:On Thu 11 Aug 2005 at 11:56AM, Eric Saxe wrote:This might sound dumb, but are we sure that processes are the resourcewhich is temporarily unavailable?I think what you are saying, Dan, is that "this might be so obvious thatit has escaped you", and you very well might be right. :)The reason I ask is IIRC these were test cases about file locks:... Running: c_lockf_10 for 0.50919 seconds Running: c_lockf_200fork: Resource temporarily unavailable Running: c_flockfork: Resource temporarily unavailable Running: c_flock_10fork: Resource temporarily unavailable Running: c_flock_200fork: Resource temporarily unavailable Running: c_fcntl_1fork: Resource temporarily unavailable Running: c_fcntl_10fork: Resource temporarily unavailable Running: c_fcntl_200fork: Resource temporarily unavailableI recently had a discussion with Devon O'Dell about how MacOS has limitedthe number of these that the OS is willing to create. Based on that conversation I opened an RFE: 6293764 RFE: resource control governing file range locking http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6293764 Thanks, -dp --Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp_______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.orgBen Cooper Quality Control Analyst Whitesmiths Pty Ltd Tel: +61 2 8912 1774 Fax: +61 2 8912 1701 Email: [EMAIL PROTECTED]This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Whitesmiths. Finally, the recipient should check this email and any attachments for the presence of viruses. Whitesmiths accepts no liability for any damage caused by any virus transmitted by this email._______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
