syscalls performance

Enrico Granata egranata at ucsd.edu
Fri Feb 25 15:42:08 EST 2011



I modified the source code to show exactly how many clock ticks it is taking for each call. It seems that the behavior hinted by Mauro Romano Trajber is actually there:
[enrico at espresso ~]$ ./syscallperf 15
4925
1190
942
942
935
942
636
577
627
621
580
591
565
580
565

I am starting to wonder if this depends on the syscall itself OR on some call optimization.. any gcc experts around?

Enrico Granata
Computer Science & Engineering Department (EBU3B) - Room 3240
office phone 858 534 9914
University of California, San Diego

On Feb 25, 2011, at 12:30 PM, Mauro Romano Trajber wrote:

> Sure, the code is attached.
> 
> 
> On Fri, Feb 25, 2011 at 5:15 PM, Daniel Baluta <daniel.baluta at gmail.com> wrote:
> On Fri, Feb 25, 2011 at 8:22 PM, Mauro Romano Trajber <trajber at gmail.com> wrote:
> > 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 ?
> 
> Can you post a pointer to your code and information about how you got
> this numbers?
> 
> thanks,
> Daniel.
> 
> <syscallperf.c>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110225/59862a7d/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: syscallperf.c
Type: application/octet-stream
Size: 745 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110225/59862a7d/attachment.obj 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110225/59862a7d/attachment-0001.html 


More information about the Kernelnewbies mailing list