All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denys Vlasenko <dvlasenk@redhat.com>
To: Denys Vlasenko <vda.linux@googlemail.com>,
	Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Oleg Nesterov <oleg@redhat.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Alexei Starovoitov <ast@plumgrid.com>,
	Will Drewry <wad@chromium.org>, Kees Cook <keescook@chromium.org>,
	X86 ML <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/4] x86: get rid of KERNEL_STACK_OFFSET
Date: Wed, 25 Feb 2015 14:25:05 +0100	[thread overview]
Message-ID: <54EDCD31.3000203@redhat.com> (raw)
In-Reply-To: <CAK1hOcONsacP+6dQQcjuk8J7XAmh1WiN+3O62tP9ib8eYxStGg@mail.gmail.com>

On 02/25/2015 01:48 PM, Denys Vlasenko wrote:
> On Wed, Feb 25, 2015 at 9:53 AM, Ingo Molnar <mingo@kernel.org> wrote:
>> But the fix should be to not touch RSP in SAVE_ARGS, to
>> keep percpu::kernel_stack as an optimized entry point -
>> with KERNEL_STACK_OFFSET pointing to.
>>
>> So NAK - this should be fixed for real.
> 
> IOW, the proposal is to set KERNEL_STACK_OFFSET
> to SIZEOF_PTREGS. I can do that.
> 
> However.
> 
> There is an ortogonal idea we were discussing: to save
> registers and construct iret frame using PUSH insns, not MOVs.
> IIRC Andy and Linus liked it. I am ambivalent: the code will be smaller,
> but might get slower (at least on some CPUs).
> If we go that way, we will require KERNEL_STACK_OFFSET = 0
> (IOW: the current patch).
> 
> The decision on how exactly we should fix KERNEL_STACK_OFFSET
> (set it to SIZEOF_PTREGS or to zero) depends on whether
> we switch to using PUSHes, or not. What do you think?

A data point. I implemented push-based creation of pt_regs
and benchmarked it. The patch is on top of all my latest
patches sent to ML.

On SandyBridge CPU, it does not get slower: seems to be 1 cycle
faster per syscall.

We lose a number of large insns there:

    text           data     bss     dec     hex filename
-   9863              0       0    9863    2687 entry_64.o
+   9671              0       0    9671    25c7 entry_64.o


diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index f505cb6..d97bd92 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -128,8 +128,6 @@ ENDPROC(native_usergs_sysret64)
  * manipulation.
  */
 	.macro FIXUP_TOP_OF_STACK tmp offset=0
-	movq $__USER_DS,SS+\offset(%rsp)
-	movq $__USER_CS,CS+\offset(%rsp)
 	movq RIP+\offset(%rsp),\tmp  /* get rip */
 	movq \tmp,RCX+\offset(%rsp)  /* copy it to rcx as sysret would do */
 	movq EFLAGS+\offset(%rsp),\tmp /* ditto for rflags->r11 */
@@ -245,14 +243,22 @@ GLOBAL(system_call_after_swapgs)
 	 * and short:
 	 */
 	ENABLE_INTERRUPTS(CLBR_NONE)
-	ALLOC_PT_GPREGS_ON_STACK 6*8 /* 6*8: space for orig_ax and iret frame */
-	movq	%rcx,RIP(%rsp)
-	movq	%r11,EFLAGS(%rsp)
-	movq    PER_CPU_VAR(old_rsp),%rcx
-	movq    %rcx,RSP(%rsp)
-	movq_cfi rax,ORIG_RAX
-	SAVE_C_REGS_EXCEPT_RAX_RCX_R11
-	movq	$-ENOSYS,RAX(%rsp)
+	/* Construct struct pt_regs on stack */
+	pushq	$__USER_DS		/* pt_regs->ss */
+	pushq	PER_CPU_VAR(old_rsp)	/* pt_regs->sp */
+	pushq	%r11			/* pt_regs->flags */
+	pushq	$__USER_CS		/* pt_regs->cs */
+	pushq	%rcx			/* pt_regs->ip */
+	pushq	%rax			/* pt_regs->orig_ax */
+	pushq	%rdi			/* pt_regs->di */
+	pushq	%rsi			/* pt_regs->si */
+	pushq	%rdx			/* pt_regs->dx */
+	pushq	%rcx			/* pt_regs->cx */
+	pushq	$-ENOSYS		/* pt_regs->ax */
+	pushq	%r8			/* pt_regs->r8 */
+	pushq	%r9			/* pt_regs->r9 */
+	pushq	%r10			/* pt_regs->r10 */
+	sub	$(7*8),%rsp /* pt_regs->r11,bp,bx,r12-15 */
 	CFI_REL_OFFSET rip,RIP
 	testl $_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,SIZEOF_PTREGS)
 	jnz tracesys



  reply	other threads:[~2015-02-25 13:25 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-24 18:51 [PATCH 1/4] x86: entry.S: tidy up several suboptimal insns Denys Vlasenko
2015-02-24 18:51 ` [PATCH 2/4] x86: get rid of KERNEL_STACK_OFFSET Denys Vlasenko
2015-02-24 19:30   ` Steven Rostedt
2015-02-24 20:02     ` Denys Vlasenko
2015-02-24 22:37   ` Andy Lutomirski
2015-02-25  9:45     ` Ingo Molnar
2015-02-25 16:14       ` Andy Lutomirski
2015-02-26 11:42         ` Ingo Molnar
2015-02-26 15:21           ` Andy Lutomirski
2015-02-26 15:29             ` Andy Lutomirski
2015-02-25  8:53   ` Ingo Molnar
2015-02-25 12:48     ` Denys Vlasenko
2015-02-25 13:25       ` Denys Vlasenko [this message]
2015-02-25 13:53         ` Ingo Molnar
2015-02-24 18:51 ` [PATCH 3/4] x86: save r11 into pt_regs->eflags on SYSCALL64 fastpath Denys Vlasenko
2015-02-24 22:44   ` Andy Lutomirski
2015-02-24 18:51 ` [PATCH 4/4] x86: save user %rsp in pt_regs->sp Denys Vlasenko
2015-02-24 22:55   ` Andy Lutomirski
2015-02-24 19:58 ` [PATCH 1/4] x86: entry.S: tidy up several suboptimal insns Borislav Petkov
2015-02-24 20:13   ` Denys Vlasenko
2015-02-24 20:36     ` Borislav Petkov
2015-02-24 22:51       ` H. Peter Anvin
2015-02-24 22:25 ` Andy Lutomirski
2015-02-24 22:52   ` H. Peter Anvin
2015-02-24 22:56     ` Andy Lutomirski
2015-02-24 23:01       ` H. Peter Anvin
2015-02-24 23:03         ` Andy Lutomirski
2015-02-24 23:26           ` Denys Vlasenko
2015-02-25  9:20     ` Ingo Molnar
2015-02-25  9:27       ` H. Peter Anvin
2015-02-25  9:39         ` Ingo Molnar
2015-02-25 14:43       ` Steven Rostedt
2015-02-25 15:40         ` Denys Vlasenko
2015-02-25 16:01           ` Steven Rostedt
2015-02-25 16:06             ` Borislav Petkov
2015-02-26 11:47             ` Ingo Molnar
2015-02-26 12:47               ` Steven Rostedt
2015-02-26 12:50               ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54EDCD31.3000203@redhat.com \
    --to=dvlasenk@redhat.com \
    --cc=ast@plumgrid.com \
    --cc=bp@alien8.de \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vda.linux@googlemail.com \
    --cc=wad@chromium.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.