1
$\begingroup$

As far as I understand we got SYSENTER/SYSEXIT instructions because system calls via interrupts were slow (right? I might be wrong though). Therefore my question is why system calls via interrupts are slow? And how do we optimize them via SYSENTER/SYSEXIT instructions? Thank you

$\endgroup$
3
$\begingroup$

There is the general rule about interrupts being slow, and the particular case of x86 CPUs.

  • x86 have had several ways to enter kernel mode : Call gates, interrupts. They are complex, microcoded instructions, requiring many register save operation and protection checks. SYSENTER/SYSEXIT are just optimised methods : For example, since the 80286, 4 protection levels were available, but rarely used (except, IIRC, by OS/2 ?) : SYSENTER/SYSEXIT support only ring 0 (user) to ring 3 (kernel)

  • On many instruction set architectures, software interrupts are used to enter kernel mode from user code. These instructions can be optimised, but, in the simplest implementation, they are handled like external hardware interrupts or MMU faults. They are slow because the pipeline must be flushed, prefetched instructions must be discarded, before jumping to the interrupt vector.

$\endgroup$
  • $\begingroup$ Doesn't SYSENTER/SYSEXIT flush pipeline? $\endgroup$ – firo Sep 18 '18 at 12:19
  • 1
    $\begingroup$ @firo : This question dates from 2015... Since last year, with Meltdown and Spectre and all that stuff, we know that Intel did not flush enough the pipeline and prediction hardware across system calls. $\endgroup$ – TEMLIB Sep 18 '18 at 19:39
2
$\begingroup$

A software interrupt (or call gate, for that matter) requires pushing a bunch of stuff onto the stack, and popping when the OS returns. SYSENTER/SYSEXIT does not.

$\endgroup$

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.