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 <[email protected]>wrote: > Hi Mauro, > > On Fri, Feb 25, 2011 at 7:03 PM, Mauro Romano Trajber <[email protected]> > 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. >
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
