> > i believe the best solution is to not call sys_vm86() with SYSENTER. The
> > reason is to not slow down all the other system calls with an extra check
> > for VM_MASK.
>
> Well... You'll also have to cover stuff like "sigreturn" etc, which _can_
> be quite timing critical.
hm. Signals themselves can be handled easily i believe - setup_frame()
modifies not only regs->eip and regs->esp but also regs->edi and regs->ebp
[the two registers carrying the SYSEXIT return EIP and ESP]. Is there any
problem to be expected here?
sigreturn can be handled by generating a SYSENTER on the stack, instead of
the 'popl %eax ; movl $,%eax ; int $0x80' we do currently.
> And there's also the issue of non-system-calls. Things like the return
> from the page fault handler could very well be speeded up using SYSEXIT,
> by just making SYSEXIT part of the regular return sequence. Basically,
> change the "restore_all" code in arch/i386/kernel/entry.S to dynamically
> switch between "iret" and "SYSEXIT" - then _every_ normal kernel exit gets
> speeded up.
Hm, these non-glibc entry points in fact are very interesting because it
can be done without changing glibc.
> No special cases. You lose by having three comparisons: you need to check
> DS, SS and weflags. But that's on the order of a few cycles, and you win
> by using SYSEXIT whenever possible - including interrupts, page faults,
> etc.
SS is destroyed and overwritten with the kernel SS by SYSENTER - i dont
think we could get around that. Can we require user-space to save any
potential fancy extra segments before doing a fastcall?
-- 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/