Thanks Enrico and Daniel, you're right. glibc was caching getpid(); but this is not the root cause of this behavior. 

Going further, I decide to use call getpid without glibc, using  syscall(SYS_getpid) to test this behavior and it happened again. 
Calling it once, the test consumes about 7k CPU cycles and 10 calls consumes about 10k CPU cycles.

Any ideas ?

On Fri, Feb 25, 2011 at 2:15 PM, Daniel Baluta <daniel.baluta@gmail.com> wrote:
Hi Mauro,

On Fri, Feb 25, 2011 at 7:03 PM, Mauro Romano Trajber <trajber@gmail.com> wrote:
> I was doing some performance tests of system calls and I find an interesting
> behavior.
> Using RDTSC to count the CPU cycles, a single call to the getpid() consumes
> about 7k of CPU clock cycles and ten calls consume approximately 9,800
> cycles.
> The fact is that from the second call, the CPU cycles grows at a rate of
> about 350 CPU cycles per call.
> Why does this happen? There is some hardware optimization when the syscall
> ID is already in EAX register ?

Use strace and check to number of getpid() syscalls.
You'll notice that only 1 system call is made, glibc caching the pid value.

thanks,
Daniel.