[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <cover.1415403984.git.luto@amacapital.net>
Date: Fri, 7 Nov 2014 15:58:16 -0800
From: Andy Lutomirski <luto@...capital.net>
To: x86@...nel.org, linux-kernel@...r.kernel.org
Cc: Frédéric Weisbecker <fweisbec@...il.com>,
Oleg Nesterov <oleg@...hat.com>,
kvm list <kvm@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>
Subject: [PATCH 0/3] x86_64,entry: Rearrange the syscall exit optimizations
The syscall exit asm is a big mess. There's a really fast path, some
kind of fast path code (with a hard-coded optimization for audit), and
the really slow path. The result is that it's very hard to work with
this code. There are some asm paths that are much slower than they
should be (context tracking is a major offender), but no one really
wants to add even more asm to speed them up.
This series takes a different, unorthodox approach. Rather than trying
to avoid entering the very slow iret path, it adds a way back out of the
iret path. The result is a dramatic speedup for context tracking, user
return notification, and similar code, as the cost of a few lines of
tricky asm. Nonetheless, it's barely a net addition of asm code,
because we get to remove the fast path optimizations for audit and
rescheduling.
Thoughts? If this works, it opens the door for a lot of further
consolidation of the exit code.
Note: patch 1 in this series has been floating around on the list
for quite a while. It's mandatory for this series to work, because
the buglet that it fixes almost completely defeats the optimization
that I'm introducing.
Andy Lutomirski (3):
x86_64,entry: Fix RCX for traced syscalls
x86_64,entry: Use sysret to return to userspace when possible
x86_64,entry: Remove the syscall exit audit and schedule optimizations
arch/x86/kernel/entry_64.S | 103 ++++++++++++++++++++++++---------------------
1 file changed, 55 insertions(+), 48 deletions(-)
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists