Re: svn commit: r220430 - head/sys/amd64/amd64
on 08/04/2011 00:32 John Baldwin said the following: Author: jhb Date: Thu Apr 7 21:32:25 2011 New Revision: 220430 URL: http://svn.freebsd.org/changeset/base/220430 Log: If a system call does not request a full interrupt return, use a fast path via the sysretq instruction to return from the system call. This was removed in 190620 and not quite fully restored in 195486. This resolves most of the performance regression in system call microbenchmarks between 7 and 8 on amd64. Reviewed by:kib MFC after: 1 week I think that this commit (plus r220431) has broken something in my environment. After updating to the most recent head I started to get semi-random problems in various areas: - named would consistently fail to start, but with different errors (assertions) - ^Z and fg result in a process getting SIGSEGV - X sometimes fails to start complaining about failed VT switch Reverting just these two commits restores sanity. Just in case, my processor is AMD (arch is obviously amd64). Modified: head/sys/amd64/amd64/exception.S Modified: head/sys/amd64/amd64/exception.S == --- head/sys/amd64/amd64/exception.S Thu Apr 7 21:29:34 2011 (r220429) +++ head/sys/amd64/amd64/exception.S Thu Apr 7 21:32:25 2011 (r220430) @@ -339,6 +339,9 @@ IDTVEC(prot) * and the new privilige level. We are still running on the old user stack * pointer. We have to juggle a few things around to find our stack etc. * swapgs gives us access to our PCPU space only. + * + * We do not support invoking this from a custom %cs or %ss (e.g. using + * entries from an LDT). */ IDTVEC(fast_syscall) swapgs @@ -380,6 +383,36 @@ IDTVEC(fast_syscall) movq%rsp,%rdi callsyscall movqPCPU(CURPCB),%rax + testq $PCB_FULL_IRET,PCB_FLAGS(%rax) + jne 3f +1: /* Check for and handle AST's on return to userland. */ + cli + movqPCPU(CURTHREAD),%rax + testl $TDF_ASTPENDING | TDF_NEEDRESCHED,TD_FLAGS(%rax) + je 2f + sti + movq%rsp, %rdi + callast + jmp 1b +2: /* Restore preserved registers. */ + MEXITCOUNT + movqTF_RDI(%rsp),%rdi /* bonus; preserve arg 1 */ + movqTF_RSI(%rsp),%rsi /* bonus: preserve arg 2 */ + movqTF_RDX(%rsp),%rdx /* return value 2 */ + movqTF_RAX(%rsp),%rax /* return value 1 */ + movqTF_RBX(%rsp),%rbx /* C preserved */ + movqTF_RBP(%rsp),%rbp /* C preserved */ + movqTF_R12(%rsp),%r12 /* C preserved */ + movqTF_R13(%rsp),%r13 /* C preserved */ + movqTF_R14(%rsp),%r14 /* C preserved */ + movqTF_R15(%rsp),%r15 /* C preserved */ + movqTF_RFLAGS(%rsp),%r11/* original %rflags */ + movqTF_RIP(%rsp),%rcx /* original %rip */ + movqTF_RSP(%rsp),%r9/* user stack pointer */ + movq%r9,%rsp/* original %rsp */ + swapgs + sysretq +3: /* Requested full context restore, use doreti for that. */ MEXITCOUNT jmp doreti -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: svn commit: r220430 - head/sys/amd64/amd64
Author: jhb Date: Thu Apr 7 21:32:25 2011 ... URL: http://svn.freebsd.org/changeset/base/220430 ... I think that this commit (plus r220431) has broken something in my environment. After updating to the most recent head I started to get semi-random problems in various areas: - named would consistently fail to start, but with different errors (assertions) - ^Z and fg result in a process getting SIGSEGV - X sometimes fails to start complaining about failed VT switch Reverting just these two commits restores sanity. Just in case, my processor is AMD (arch is obviously amd64). I experienced similar problems (UP amd64, AMD Mobile Athlon64 processor) and reported it to kib@ and jhb@. b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: svn commit: r220430 - head/sys/amd64/amd64
08.04.2011 14:23, Andriy Gapon пишет: on 08/04/2011 00:32 John Baldwin said the following: Author: jhb Date: Thu Apr 7 21:32:25 2011 New Revision: 220430 URL: http://svn.freebsd.org/changeset/base/220430 Log: If a system call does not request a full interrupt return, use a fast path via the sysretq instruction to return from the system call. This was removed in 190620 and not quite fully restored in 195486. This resolves most of the performance regression in system call microbenchmarks between 7 and 8 on amd64. Reviewed by: kib MFC after: 1 week I think that this commit (plus r220431) has broken something in my environment. After updating to the most recent head I started to get semi-random problems in various areas: - named would consistently fail to start, but with different errors (assertions) - ^Z and fg result in a process getting SIGSEGV - X sometimes fails to start complaining about failed VT switch Reverting just these two commits restores sanity. Just in case, my processor is AMD (arch is obviously amd64). confirm Modified: head/sys/amd64/amd64/exception.S Modified: head/sys/amd64/amd64/exception.S == --- head/sys/amd64/amd64/exception.SThu Apr 7 21:29:34 2011 (r220429) +++ head/sys/amd64/amd64/exception.SThu Apr 7 21:32:25 2011 (r220430) @@ -339,6 +339,9 @@ IDTVEC(prot) * and the new privilige level. We are still running on the old user stack * pointer. We have to juggle a few things around to find our stack etc. * swapgs gives us access to our PCPU space only. + * + * We do not support invoking this from a custom %cs or %ss (e.g. using + * entries from an LDT). */ IDTVEC(fast_syscall) swapgs @@ -380,6 +383,36 @@ IDTVEC(fast_syscall) movq%rsp,%rdi callsyscall movqPCPU(CURPCB),%rax + testq $PCB_FULL_IRET,PCB_FLAGS(%rax) + jne 3f +1: /* Check for and handle AST's on return to userland. */ + cli + movqPCPU(CURTHREAD),%rax + testl $TDF_ASTPENDING | TDF_NEEDRESCHED,TD_FLAGS(%rax) + je 2f + sti + movq%rsp, %rdi + callast + jmp 1b +2: /* Restore preserved registers. */ + MEXITCOUNT + movqTF_RDI(%rsp),%rdi /* bonus; preserve arg 1 */ + movqTF_RSI(%rsp),%rsi /* bonus: preserve arg 2 */ + movqTF_RDX(%rsp),%rdx /* return value 2 */ + movqTF_RAX(%rsp),%rax /* return value 1 */ + movqTF_RBX(%rsp),%rbx /* C preserved */ + movqTF_RBP(%rsp),%rbp /* C preserved */ + movqTF_R12(%rsp),%r12 /* C preserved */ + movqTF_R13(%rsp),%r13 /* C preserved */ + movqTF_R14(%rsp),%r14 /* C preserved */ + movqTF_R15(%rsp),%r15 /* C preserved */ + movqTF_RFLAGS(%rsp),%r11/* original %rflags */ + movqTF_RIP(%rsp),%rcx /* original %rip */ + movqTF_RSP(%rsp),%r9/* user stack pointer */ + movq%r9,%rsp/* original %rsp */ + swapgs + sysretq +3: /* Requested full context restore, use doreti for that. */ MEXITCOUNT jmp doreti ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: svn commit: r220430 - head/sys/amd64/amd64
On 4/8/11 6:23 AM, Andriy Gapon wrote: on 08/04/2011 00:32 John Baldwin said the following: Author: jhb Date: Thu Apr 7 21:32:25 2011 New Revision: 220430 URL: http://svn.freebsd.org/changeset/base/220430 Log: If a system call does not request a full interrupt return, use a fast path via the sysretq instruction to return from the system call. This was removed in 190620 and not quite fully restored in 195486. This resolves most of the performance regression in system call microbenchmarks between 7 and 8 on amd64. Reviewed by: kib MFC after: 1 week I think that this commit (plus r220431) has broken something in my environment. After updating to the most recent head I started to get semi-random problems in various areas: - named would consistently fail to start, but with different errors (assertions) - ^Z and fg result in a process getting SIGSEGV - X sometimes fails to start complaining about failed VT switch Reverting just these two commits restores sanity. Just in case, my processor is AMD (arch is obviously amd64). I think I've found this (I got a bunch of weird core dumps overnight, too). The problem is that ast() can context switch in which case PCB_FULL_IRET might get set, but this code would still do the fast path after ast() returned. I fixed it to recheck the PCB_FULL_IRET flag after returning from ast() and that has fixed the core dumps I was seeing overnight. I also fixed a bug where PCB_FULL_IRET wasn't updated in some of the ia32 compat code, a typo in a comment, and trimmed an extra mov from the doreti path: Index: amd64/exception.S === --- amd64/exception.S (revision 221092) +++ amd64/exception.S (working copy) @@ -382,10 +382,10 @@ FAKE_MCOUNT(TF_RIP(%rsp)) movq%rsp,%rdi callsyscall - movqPCPU(CURPCB),%rax +1: movqPCPU(CURPCB),%rax testl $PCB_FULL_IRET,PCB_FLAGS(%rax) - jne 3f -1: /* Check for and handle AST's on return to userland. */ + jnz 3f + /* Check for and handle AST's on return to userland. */ cli movqPCPU(CURTHREAD),%rax testl $TDF_ASTPENDING | TDF_NEEDRESCHED,TD_FLAGS(%rax) @@ -661,7 +661,7 @@ doreti_ast: /* * Check for ASTs atomically with returning. Disabling CPU -* interrupts provides sufficient locking eve in the SMP case, +* interrupts provides sufficient locking even in the SMP case, * since we will be informed of any new ASTs by an IPI. */ cli @@ -682,8 +682,7 @@ */ doreti_exit: MEXITCOUNT - movqPCPU(CURTHREAD),%r8 - movqTD_PCB(%r8),%r8 + movqPCPU(CURPCB),%r8 /* * Do not reload segment registers for kernel. Index: ia32/ia32_exception.S === --- ia32/ia32_exception.S (revision 221079) +++ ia32/ia32_exception.S (working copy) @@ -46,7 +46,7 @@ subq$TF_ERR,%rsp/* skip over tf_trapno */ movq%rdi,TF_RDI(%rsp) movqPCPU(CURPCB),%rdi - movb$0,PCB_FULL_IRET(%rdi) + andl$~PCB_FULL_IRET,PCB_FLAGS(%rdi) movw%fs,TF_FS(%rsp) movw%gs,TF_GS(%rsp) movw%es,TF_ES(%rsp) -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
