From mboxrd@z Thu Jan 1 00:00:00 1970 From: egranata@ucsd.edu (Enrico Granata) Date: Fri, 25 Feb 2011 09:14:18 -0800 Subject: syscalls performance References: Message-ID: <2FC98D6E-3CBF-4092-A435-FDFA9ECDAC16@cs.ucsd.edu> To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org If you are calling getpid() as a libc function, the library is caching the result. This means, after the first time calling it (when you really have to go into the kernel), subsequent calls will simply return the cached value without ever leaving user level Enrico Granata Computer Science & Engineering Department (EBU3B) - Room 3240 office phone 858 534 9914 University of California, San Diego > On Feb 25, 2011, at 9:03 AM, Mauro Romano Trajber 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 ? >> >> Any ideias ? >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies at kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110225/dc975a60/attachment.html