In older versions of linux architecture, system calls would always generate an interrupt during their execution. They would be executed by setting the system call number into %eax and parameters into %ebx, %ecx and so on, followed by issuing the specific interrupt int 0x80. Thus, system calls could be said to be a common cause of software interrupts on a system.

However, on modern architectures of x86_64 there is a specific system call instruction "syscall", which bypasses the need to use interrupt 0x80, and thus, the interrupt descriptor table at all. While I believe the previous method of generating an interrupt for syscall is still supported, the syscall instruction seems to be the way it's done in practice.

Thus, my question is: Is it no longer correct to say that system calls generate interrupts? Would a system call still increment the number seen in the "interrupts" column output of vmstat, for example?


Yes, modern C code for Linux x86_64 uses the syscall instruction, see for example glibc sysdeps/unix/sysv/linux/x86_64/syscall.S. No, this does not mean system call interrupts go away, due to compatibility.


The x86 architecture has quite a few different ways to jump into kernel code. Most of these entry points are registered in arch/x86/kernel/traps.c and implemented in arch/x86/entry/entry_64.S for 64-bit, arch/x86/entry/entry_32.S for 32-bit and finally arch/x86/entry/entry_64_compat.S which implements the 32-bit compatibility syscall entry points and thus provides for 32-bit processes the ability to execute syscalls when running on 64-bit kernels.

The IDT vector assignments are listed in arch/x86/include/asm/irq_vectors.h.

Some of these entries are:

  • system_call: syscall instruction from 64-bit code.

  • entry_INT80_compat: int 0x80 from 32-bit or 64-bit code; compat syscall either way.

  • entry_INT80_compat, ia32_sysenter: syscall and sysenter from 32-bit code

And for read only syscalls (gettimeofday) there is vDSO which does not enter kernel mode at all.

system calls can be profiled in a few ways, such as ftrace or eBPF. In addition to being obsolete in 64 bit mode, interrupts happen for reasons other than system calls.

  • Thank you for this great explanation. To make sure I fully understand, syscalls will still generate interrupts due to compatibility with entry points such as you described for "entry_INT80_compat" which may be used by either 32-bit or 64-bit code and will still incur a traditional interrupt. However, if syscall instruction is used from 64-bit code, then a traditional software interrupt would not occur. Do I understand correctly? – arrwags Oct 30 '17 at 5:07
  • 1
    Causation is the other way around: 32 bit C code uses interrupts to call syscalls. Correct, interrupts are not used for the 64 bit mode syscall instruction, compare the implementation in your favorite C library. All of this only discusses x86 architecture, by the way. – John Mahowald Oct 30 '17 at 14:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.