Programming

Otheus -
utimes is the call made by

Code:

 time <command>

It gives cumulative times for user and kernel, as well as cum process wall time.
Call it for a starting set of values and an ending set of values, then substract for a delta value.

Sorry - a little off track - I don't see where the OP has tried running ltrace with syscalls enabled - or strace.

The differences probably are due to OS implementation - maybe a lot of calls to brk in one OS and not the other. It's worth the 2 minutes it takes to execute Otheus' code under strace on each box. That would rule out an odd kernel setting or some implementation "feature" as the root cause of the differences. If you see odd behavior, like a lot of system calls on one box and not on the the other, maybe someone can relate that to something useful.

I think you are confused. utime() and utimes() operate on an inode to change timestamps of files.

to Otheus:
gprof -l complains about missing call-graph data, which I don't quite understand, but that is beyond the point in this thread.

to Jim:

On SCO
$ truss ./tstloop
semsys(1, 2819742, 2, 0, 0, 0) = 18827
semsys(0, 18827, 2, 6, 2147483024, 0) = 0
.
.
.
repeats on and on for 5,000,000 times, as coded.
I don't see any brk here.

On Linux
$ strace -Tc ./tstloop
time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
50.85 62.145774 29 2134526 semctl
49.15 60.059067 28 2134527 semget
0.00 0.000088 18 5 old_mmap
0.00 0.000054 18 3 mprotect
0.00 0.000039 20 2 open
0.00 0.000028 14 2 fstat64
0.00 0.000025 13 2 close
0.00 0.000020 20 1 munmap
0.00 0.000018 18 1 read
0.00 0.000018 18 1 uname
0.00 0.000018 18 1 stat64
0.00 0.000014 14 1 1 access
0.00 0.000014 14 1 set_thread_area
0.00 0.000012 12 1 time
0.00 0.000008 8 1 brk
------ ----------- ----------- --------- --------- ----------------
100.00 122.205197 4269075 1 total

when I try
$ strace ./tstloop
semget(1660977153, 2, IPC_CREAT|0777) = 32769 <0.000028>
semctl(32769, 2, IPC_64|GETALL, 0xfeead064) = 0 <0.000029>
.
.
.

Does this output clarifies anything?

Just to be clear, did you try "gprof -p -l" ?


Also, according to this page, you can run "truss -c" on SCO to get similar summary results. If we're lucky, you get per-system-call time, as shown above by ltrace -Tc on Linux. Then you can get what we're really after -- how much time does Linux spend in each system call versus SCO.

SCO has kernel parameter issues with semphores. SHMMAX parameter by default is small. This is a known issue. Here is SCO docset for installing Postgres that discusses it.

Managing Kernel Resources

There are directions for viewing the SHMMAX setting . If it is default, consider raising the value and see if it resolves the shared memory problems you are having.

Otheus -

you are correct - times() uses struct tms not utimes(). That was my bad.

Jim, Are you thinking that the size of SHMxxx parameters influences the performance?

Migurus,

What do you have set for your Linux shared memory settings? "/sbin/sysctl -a |grep shm". (Ignore errors). Compare those to what is set for SCO (I don't know how to get those).