Messages in this thread | | | Date | Fri, 4 Sep 1998 16:03:17 +0200 (CEST) | From | MOLNAR Ingo <> | Subject | Re: 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
| |