This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: random performance of sem_post function


I'm using RHEL 6.2 64 bits on a regular intel nehalem server. I also have that behavior on Centos 5.3 with the same kind of HW.
I'll try oprofile, I never used it so I hope it doesn't require root privileges as I don't have any. I tried intel Vtune and perf but wasn't able to see anything interesting (just like the sem_post function wasn't taking any CPU time) but I must say there are lots of HW counters I don't know how to use.

Could it be possible to control the behavior of the syscall function ? Because the executable that shows that issue is also linked with some code I've no control on.

Olivier
________________________________________
From: Carlos O'Donell [carlos@systemhalted.org]
Sent: Friday, January 04, 2013 20:10
To: Maury, Olivier
Cc: libc-help@sourceware.org
Subject: Re: random performance of sem_post function

On 01/04/2013 12:21 PM, Maury, Olivier wrote:
> What is very strange is that this simple sem_post function is not
> tacking the same amount of time in both executables. In one of them
> the order of magnitude of the function call is almost all the time
> about 1e-5s while in the other one it's goes from 1e-5s (very rare)
> to 1e-2s (quite often).

1e-2s is 100Hz, which might be approximately the scheduling frequency
depending on your kernel and target architecture. Modern systems use
1000Hz ticks e.g. 1e-3s.

I suggest using oprofile to determine what the CPUs and threads
are actually doing.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]