Thanks Enrico and Daniel, you're right. glibc was caching getpid(); but this is not the root cause of this behavior. <div><br></div><div>Going further, I decide to use call getpid without glibc, using syscall(SYS_getpid) to test this behavior and it happened again. </div>
<div>Calling it once, the test consumes about 7k CPU cycles and 10 calls consumes about 10k CPU cycles.</div><div><br></div><div>Any ideas ?</div><div><br></div><div><div class="gmail_quote">On Fri, Feb 25, 2011 at 2:15 PM, Daniel Baluta <span dir="ltr"><<a href="mailto:daniel.baluta@gmail.com">daniel.baluta@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Mauro,<br>
<div><div></div><div class="h5"><br>
On Fri, Feb 25, 2011 at 7:03 PM, Mauro Romano Trajber <<a href="mailto:trajber@gmail.com">trajber@gmail.com</a>> wrote:<br>
> I was doing some performance tests of system calls and I find an interesting<br>
> behavior.<br>
> Using RDTSC to count the CPU cycles, a single call to the getpid() consumes<br>
> about 7k of CPU clock cycles and ten calls consume approximately 9,800<br>
> cycles.<br>
> The fact is that from the second call, the CPU cycles grows at a rate of<br>
> about 350 CPU cycles per call.<br>
> Why does this happen? There is some hardware optimization when the syscall<br>
> ID is already in EAX register ?<br>
<br>
</div></div>Use strace and check to number of getpid() syscalls.<br>
You'll notice that only 1 system call is made, glibc caching the pid value.<br>
<br>
thanks,<br>
<font color="#888888">Daniel.<br>
</font></blockquote></div><br></div>