lkml.org 
[lkml]   [1998]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Differences between FreeBSD and Linux system call mechanism

On 4 Sep 1998, H. Peter Anvin wrote:

> It loses because it throws away %eip and %esp, requiring those values
> to be saved in user space, and giving you no indication where you came
> from. Oh yes, and it loses because it works from V86 mode, with no
> way to tell you were coming from V86 mode and hence shouldn't execute
> arbitrary system calls. The only way around that is to zero the
> SYSENTER MSR *in the scheduler*, slowing down a common path because
> you can't put a needed test in an uncommon path.
>
> (Actually, there is a better alternative: the vm86() system call
> should set a flag in the process structure, and the signal handlers
> should clear it; if you get a SYSENTER with the flag set you know you
> were in V86 mode. Note that since %cs, %ss, %eip and %esp are
> irrecoverably lost, all you can do is shut the V86 process down, or
> emulate an 8086 reset.)

hm, do we want to correctly handle rouge SYSENTER from vm86() processes
nicely? %eip and %esp are not lost. You can fake an %esp anytime with an
interrupt gate too. %eip and %esp are not in their native registers and
locations, is this a problem? My patch solves this (and more problems like
enabling IRQs which is another dumb thing btw) and it's still more than
twice as fast as INT based entry. And it's not even heavily optimized.

_even_ if we have to manipulate MSRs in schedule(), it's not nearly as bad
as you think. First, there are 2-3 orders less context switches in a
typical Linux box than system entries. Second, if you think about it, even
the worst case SYSENTER+schedule_new() is faster than INT+schedule_old(),
because the only way to get into the kernel is a system entry ... and with
SYSENTER you already have saved 150 cycles, so you can well spend those
20-30 cycles to do the MSR manipulation. The two functions (system_call
and schedule) can never be measured separately, so it's possible that all
lmbench numbers get faster even if schedule() [the function] got slightly
slower). And the typical case is thousands of system calls per context
switch.

-- mingo



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.050 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site