Date: Fri, 08 Apr 2011 16:32:47 +0400 From: Alex Keda <admin@lissyara.su> To: freebsd-current@freebsd.org Subject: Re: svn commit: r220430 - head/sys/amd64/amd64 Message-ID: <4D9F006F.3020803@lissyara.su> In-Reply-To: <4D9EE221.40200@FreeBSD.org> References: <201104072132.p37LWPuu052536@svn.freebsd.org> <4D9EE221.40200@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.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 >> call syscall >> movq PCPU(CURPCB),%rax >> + testq $PCB_FULL_IRET,PCB_FLAGS(%rax) >> + jne 3f >> +1: /* Check for and handle AST's on return to userland. */ >> + cli >> + movq PCPU(CURTHREAD),%rax >> + testl $TDF_ASTPENDING | TDF_NEEDRESCHED,TD_FLAGS(%rax) >> + je 2f >> + sti >> + movq %rsp, %rdi >> + call ast >> + jmp 1b >> +2: /* Restore preserved registers. */ >> + MEXITCOUNT >> + movq TF_RDI(%rsp),%rdi /* bonus; preserve arg 1 */ >> + movq TF_RSI(%rsp),%rsi /* bonus: preserve arg 2 */ >> + movq TF_RDX(%rsp),%rdx /* return value 2 */ >> + movq TF_RAX(%rsp),%rax /* return value 1 */ >> + movq TF_RBX(%rsp),%rbx /* C preserved */ >> + movq TF_RBP(%rsp),%rbp /* C preserved */ >> + movq TF_R12(%rsp),%r12 /* C preserved */ >> + movq TF_R13(%rsp),%r13 /* C preserved */ >> + movq TF_R14(%rsp),%r14 /* C preserved */ >> + movq TF_R15(%rsp),%r15 /* C preserved */ >> + movq TF_RFLAGS(%rsp),%r11 /* original %rflags */ >> + movq TF_RIP(%rsp),%rcx /* original %rip */ >> + movq TF_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 >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D9F006F.3020803>