Gavin, On 4/7/06 3:27 PM, "Gavin Hamill" <gdh@xxxxxxxxxxxxx> wrote: > 278774: __semop(15728650, 0x0FFFFFFFFFFF7E80, 1) = 0 > 155712: __semop(15728650, 0x0FFFFFFFFFFF5920, 1) = 0 > 278774: __semop(15728649, 0x0FFFFFFFFFFF6F10, 1) > 114914: __semop(15728649, 0x0FFFFFFFFFFF6A40, 1) = 0 = 0 > 114914: __semop(15728650, 0x0FFFFFFFFFFF61E0, 1) > 155712: __semop(15728650, 0x0FFFFFFFFFFF6850, 1) = 0 = 0 > 155712: __semop(15728650, 0x0FFFFFFFFFFF6890, 1) = 0 1 > 55712: __semop(15728650, 0x0FFFFFFFFFFF5920, 1) > 278774: __semop(15728650, 0x0FFFFFFFFFFF6F10, 1) > 155712: __semop(15728650, 0x0FFFFFFFFFFF6850, 1) = 0 = 0 > 278774: __semop(15728649, 0x0FFFFFFFFFFF7E40, 1) > 114914: __semop(15728649, 0x0FFFFFFFFFFF6A80, 1) = 0 = 0 > 278774: __semop(15728650, 0x0FFFFFFFFFFF7E80, 1) Seems like you're hitting a very small target in RAM with these semop calls. I wonder what part of the code is doing this - Tom would know better how to trace it, but the equivalent of oprofile output would be nice. The other thing that I'd like to see is an evaluation of the memory access latency of this machine from Register to RAM. I couldn't find a benchmarking tool that was UNIX friendly out there, maybe I'll write one real quick. I suspect this machine has a heinous latency and a storm of semops to the same spot of RAM might be a far worse performance problem on this machine than on others... - Luke
