I just started studying about system calls. I would like to know what causes overhead when a system call is made.
For example, if we consider getpid(), when a system call is made to getpid() my guess is that if the control is currently in the child process then a context switching has to be made to enter the parent process to get the pid. Can that contribute to overhead?
Also when getpid() is called, there will be some metadata transfer across the user-space boundary and enters and exits the kernel.So will the constant switching between user space and kernel also cause some overhead?
For example, if we consider getpid(), when a system call is made to getpid() my guess is that if the control is currently in the child process then a context switching has to be made to enter the parent process to get the pid.
No context switch to the child process should be necessary here — the kernel should have all of the necessary data available to itself. In most cases, the kernel will only switch contexts to a userspace process in the scheduler, or when returning from a system call.
Also when getpid() is called, there will be some metadata transfer across the user-space boundary and enters and exits the kernel. So will the constant switching between user space and kernel also cause some overhead?
Yes, if getpid() was being called often, the overhead would certainly build up. There are some approaches available which can avoid this overhead for simple "getter" system calls like getpid() and gettimeofday(); one such approach which was at one point used under Linux was to store the (known) result of the system call in a special memory page. (This mechanism was known as vsyscall.)