Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1285995 > unrolled thread

[PATCH 00/12] x86: Rewrite 64-bit syscall code

Started byAndy Lutomirski <luto@kernel.org>
First post2015-12-07 23:00 +0100
Last post2015-12-08 08:10 +0100
Articles 6 — 3 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH 00/12] x86: Rewrite 64-bit syscall code Andy Lutomirski <luto@kernel.org> - 2015-12-07 23:00 +0100
    [PATCH 09/12] x86/entry/64: Stop using int_ret_from_sys_call in ret_from_fork Andy Lutomirski <luto@kernel.org> - 2015-12-07 23:00 +0100
    Re: [PATCH 00/12] x86: Rewrite 64-bit syscall code Andy Lutomirski <luto@amacapital.net> - 2015-12-08 00:00 +0100
      Re: [PATCH 00/12] x86: Rewrite 64-bit syscall code Ingo Molnar <mingo@kernel.org> - 2015-12-08 05:50 +0100
        Re: [PATCH 00/12] x86: Rewrite 64-bit syscall code Andy Lutomirski <luto@amacapital.net> - 2015-12-08 06:50 +0100
          Re: [PATCH 00/12] x86: Rewrite 64-bit syscall code Ingo Molnar <mingo@kernel.org> - 2015-12-08 08:10 +0100

#1285995 — [PATCH 00/12] x86: Rewrite 64-bit syscall code

FromAndy Lutomirski <luto@kernel.org>
Date2015-12-07 23:00 +0100
Subject[PATCH 00/12] x86: Rewrite 64-bit syscall code
Message-ID<qDbZ7-1Mo-3@gated-at.bofh.it>
This is kind of like the 32-bit and compat code, except that I
preserved the fast path this time.  I was unable to measure any
significant performance change on my laptop in the fast path.

What do you all think?

Andy Lutomirski (12):
  selftests/x86: Extend Makefile to allow 64-bit only tests
  selftests/x86: Add check_initial_reg_state
  x86/syscalls: Refactor syscalltbl.sh
  x86/syscalls: Remove __SYSCALL_COMMON and __SYSCALL_X32
  x86/syscalls: Move compat syscall entry handling into syscalltbl.sh
  x86/syscalls: Add syscall entry qualifiers
  x86/entry/64: Always run ptregs-using syscalls on the slow path
  x86/entry/64: Call all native slow-path syscalls with full pt-regs
  x86/entry/64: Stop using int_ret_from_sys_call in ret_from_fork
  x86/entry/64: Migrate the 64-bit syscall slow path to C
  x86/entry/32: Change INT80 to be an interrupt gate
  x86/entry: Do enter_from_user_mode with IRQs off

 arch/x86/entry/common.c                            |  80 +++----
 arch/x86/entry/entry_32.S                          |   8 +-
 arch/x86/entry/entry_64.S                          | 245 ++++++---------------
 arch/x86/entry/entry_64_compat.S                   |   2 +-
 arch/x86/entry/syscall_32.c                        |  10 +-
 arch/x86/entry/syscall_64.c                        |  30 ++-
 arch/x86/entry/syscalls/syscall_64.tbl             |  18 +-
 arch/x86/entry/syscalls/syscalltbl.sh              |  58 ++++-
 arch/x86/include/asm/thread_info.h                 |   5 +-
 arch/x86/kernel/asm-offsets_32.c                   |   2 +-
 arch/x86/kernel/asm-offsets_64.c                   |  10 +-
 arch/x86/kernel/traps.c                            |   2 +-
 arch/x86/um/sys_call_table_32.c                    |   4 +-
 arch/x86/um/sys_call_table_64.c                    |   7 +-
 arch/x86/um/user-offsets.c                         |   6 +-
 tools/testing/selftests/x86/Makefile               |  13 +-
 .../selftests/x86/check_initial_reg_state.c        | 108 +++++++++
 17 files changed, 330 insertions(+), 278 deletions(-)
 create mode 100644 tools/testing/selftests/x86/check_initial_reg_state.c

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1285997 — [PATCH 09/12] x86/entry/64: Stop using int_ret_from_sys_call in ret_from_fork

FromAndy Lutomirski <luto@kernel.org>
Date2015-12-07 23:00 +0100
Subject[PATCH 09/12] x86/entry/64: Stop using int_ret_from_sys_call in ret_from_fork
Message-ID<qDbZa-1Mo-75@gated-at.bofh.it>
In reply to#1285995
ret_from_fork is now open-coded and is no longer tangled up with the
syscall code.  This isn't so bad -- this adds very little code, and
IMO the result is much easier to understand.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
 arch/x86/entry/entry_64.S | 35 +++++++++++++++++++----------------
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 8a6b7ce2beff..81b0944708c5 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -363,7 +363,6 @@ END(stub_ptregs_64)
  * rdi: prev task we switched from
  */
 ENTRY(ret_from_fork)
-
 	LOCK ; btr $TIF_FORK, TI_flags(%r8)
 
 	pushq	$0x0002
@@ -371,28 +370,32 @@ ENTRY(ret_from_fork)
 
 	call	schedule_tail			/* rdi: 'prev' task parameter */
 
-	RESTORE_EXTRA_REGS
-
 	testb	$3, CS(%rsp)			/* from kernel_thread? */
+	jnz	1f
 
 	/*
-	 * By the time we get here, we have no idea whether our pt_regs,
-	 * ti flags, and ti status came from the 64-bit SYSCALL fast path,
-	 * the slow path, or one of the 32-bit compat paths.
-	 * Use IRET code path to return, since it can safely handle
-	 * all of the above.
+	 * We came from kernel_thread.  This code path is quite twisted, and
+	 * someone should clean it up.
+	 *
+	 * copy_thread_tls stashes the function pointer in RBX and the
+	 * parameter to be passed in RBP.  The called function is permitted
+	 * to call do_execve and thereby jump to user mode.
 	 */
-	jnz	int_ret_from_sys_call
+	movq	RBP(%rsp), %rdi
+	call	*RBX(%rsp)
+	movl	$0, RAX(%rsp)
 
 	/*
-	 * We came from kernel_thread
-	 * nb: we depend on RESTORE_EXTRA_REGS above
+	 * Fall through as though we're exiting a syscall.  This makes a
+	 * twisted sort of sense if we just called do_execve.
 	 */
-	movq	%rbp, %rdi
-	call	*%rbx
-	movl	$0, RAX(%rsp)
-	RESTORE_EXTRA_REGS
-	jmp	int_ret_from_sys_call
+
+1:
+	movq	%rsp, %rdi
+	call	syscall_return_slowpath	/* returns with IRQs disabled */
+	TRACE_IRQS_ON			/* user mode is traced as IRQS on */
+	SWAPGS
+	jmp	restore_regs_and_iret
 END(ret_from_fork)
 
 /*
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1286078

FromAndy Lutomirski <luto@amacapital.net>
Date2015-12-08 00:00 +0100
Message-ID<qDcVc-2rG-17@gated-at.bofh.it>
In reply to#1285995

[Multipart message — attachments visible in raw view] — view raw

On Mon, Dec 7, 2015 at 1:51 PM, Andy Lutomirski <luto@kernel.org> wrote:
> This is kind of like the 32-bit and compat code, except that I
> preserved the fast path this time.  I was unable to measure any
> significant performance change on my laptop in the fast path.
>
> What do you all think?

For completeness, if I zap the fast path entirely (see attached), I
lose 20 cycles (148 cycles vs 128 cycles) on Skylake.  Switching
between movq and pushq for stack setup makes no difference whatsoever,
interestingly.  I haven't tried to figure out exactly where those 20
cycles go.

--Andy

[toc] | [prev] | [next] | [standalone]

#1286231

FromIngo Molnar <mingo@kernel.org>
Date2015-12-08 05:50 +0100
Message-ID<qDinT-5Zg-3@gated-at.bofh.it>
In reply to#1286078
* Andy Lutomirski <luto@amacapital.net> wrote:

> On Mon, Dec 7, 2015 at 1:51 PM, Andy Lutomirski <luto@kernel.org> wrote:
>
> > This is kind of like the 32-bit and compat code, except that I preserved the 
> > fast path this time.  I was unable to measure any significant performance 
> > change on my laptop in the fast path.
> >
> > What do you all think?
> 
> For completeness, if I zap the fast path entirely (see attached), I lose 20 
> cycles (148 cycles vs 128 cycles) on Skylake.  Switching between movq and pushq 
> for stack setup makes no difference whatsoever, interestingly.  I haven't tried 
> to figure out exactly where those 20 cycles go.

So I asked for this before, and I'll do so again: could you please stick the cycle 
granular system call performance test into a 'perf bench' variant so that:

 1) More people can run it all on various pieces of hardware and help out quantify
    the patches.

 2) We can keep an eye on not regressing base system call performance in the
    future, with a good in-tree testcase.

Thanks!!

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1286252

FromAndy Lutomirski <luto@amacapital.net>
Date2015-12-08 06:50 +0100
Message-ID<qDjjX-6BM-3@gated-at.bofh.it>
In reply to#1286231
On Mon, Dec 7, 2015 at 8:42 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Andy Lutomirski <luto@amacapital.net> wrote:
>
>> On Mon, Dec 7, 2015 at 1:51 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>
>> > This is kind of like the 32-bit and compat code, except that I preserved the
>> > fast path this time.  I was unable to measure any significant performance
>> > change on my laptop in the fast path.
>> >
>> > What do you all think?
>>
>> For completeness, if I zap the fast path entirely (see attached), I lose 20
>> cycles (148 cycles vs 128 cycles) on Skylake.  Switching between movq and pushq
>> for stack setup makes no difference whatsoever, interestingly.  I haven't tried
>> to figure out exactly where those 20 cycles go.
>
> So I asked for this before, and I'll do so again: could you please stick the cycle
> granular system call performance test into a 'perf bench' variant so that:
>
>  1) More people can run it all on various pieces of hardware and help out quantify
>     the patches.
>
>  2) We can keep an eye on not regressing base system call performance in the
>     future, with a good in-tree testcase.
>

Is it okay if it's not particularly shiny or modular?  The tool I'm
using is here:

https://git.kernel.org/cgit/linux/kernel/git/luto/misc-tests.git/tree/tight_loop/perf_self_monitor.c

and I can certainly stick it into 'perf bench' pretty easily.  Can I
leave making it into a proper library to some future contributor?

It's actually decently fancy.  It allocates a perf self-monitoring
instance that counts cycles, and then it takes a bunch of samples and
discards any that flagged a context switch.  It does some very
rudimentary statistics on the rest.  It's utterly devoid of a fancy
UI, though.

It works very well on native, and it works better than I had expected
under KVM.  (KVM traps RDPMC because neither Intel nor AMD has seen
fit to provide any sensible way to virtualize RDPMC without exiting.)

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1286287

FromIngo Molnar <mingo@kernel.org>
Date2015-12-08 08:10 +0100
Message-ID<qDkzn-7AN-1@gated-at.bofh.it>
In reply to#1286252
* Andy Lutomirski <luto@amacapital.net> wrote:

> On Mon, Dec 7, 2015 at 8:42 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Andy Lutomirski <luto@amacapital.net> wrote:
> >
> >> On Mon, Dec 7, 2015 at 1:51 PM, Andy Lutomirski <luto@kernel.org> wrote:
> >>
> >> > This is kind of like the 32-bit and compat code, except that I preserved the
> >> > fast path this time.  I was unable to measure any significant performance
> >> > change on my laptop in the fast path.
> >> >
> >> > What do you all think?
> >>
> >> For completeness, if I zap the fast path entirely (see attached), I lose 20
> >> cycles (148 cycles vs 128 cycles) on Skylake.  Switching between movq and pushq
> >> for stack setup makes no difference whatsoever, interestingly.  I haven't tried
> >> to figure out exactly where those 20 cycles go.
> >
> > So I asked for this before, and I'll do so again: could you please stick the cycle
> > granular system call performance test into a 'perf bench' variant so that:
> >
> >  1) More people can run it all on various pieces of hardware and help out quantify
> >     the patches.
> >
> >  2) We can keep an eye on not regressing base system call performance in the
> >     future, with a good in-tree testcase.
> >
> 
> Is it okay if it's not particularly shiny or modular? [...]

Absolutely!

> [...]  The tool I'm using is here:
> 
> https://git.kernel.org/cgit/linux/kernel/git/luto/misc-tests.git/tree/tight_loop/perf_self_monitor.c
> 
> and I can certainly stick it into 'perf bench' pretty easily.  Can I
> leave making it into a proper library to some future contributor?

Sure - 'perf bench' tests aren't librarized generally - the goal is to make it 
easy to create a new measurement.

> It's actually decently fancy.  It allocates a perf self-monitoring
> instance that counts cycles, and then it takes a bunch of samples and
> discards any that flagged a context switch.  It does some very
> rudimentary statistics on the rest.  It's utterly devoid of a fancy
> UI, though.
> 
> It works very well on native, and it works better than I had expected
> under KVM.  (KVM traps RDPMC because neither Intel nor AMD has seen
> fit to provide any sensible way to virtualize RDPMC without exiting.)

Sounds fantastic to me!

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web