Messages in this thread | | | Date | Wed, 8 Dec 1999 21:48:05 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: 2.3.30pre1 syscall w/6 args support? |
| |
On Wed, 8 Dec 1999, Linus Torvalds wrote:
> > 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/
| |