Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753276AbbBYPlM (ORCPT ); Wed, 25 Feb 2015 10:41:12 -0500 Received: from mail-qa0-f54.google.com ([209.85.216.54]:37648 "EHLO mail-qa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752557AbbBYPlK (ORCPT ); Wed, 25 Feb 2015 10:41:10 -0500 MIME-Version: 1.0 In-Reply-To: <20150225094312.2cfff453@gandalf.local.home> References: <1424803895-4420-1-git-send-email-dvlasenk@redhat.com> <54ED00B5.3020203@zytor.com> <20150225092043.GB16165@gmail.com> <20150225094312.2cfff453@gandalf.local.home> From: Denys Vlasenko Date: Wed, 25 Feb 2015 16:40:49 +0100 Message-ID: Subject: Re: [PATCH 1/4] x86: entry.S: tidy up several suboptimal insns To: Steven Rostedt Cc: Ingo Molnar , "H. Peter Anvin" , Andy Lutomirski , Denys Vlasenko , Linus Torvalds , Borislav Petkov , Oleg Nesterov , Frederic Weisbecker , Alexei Starovoitov , Will Drewry , Kees Cook , X86 ML , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1349 Lines: 28 On Wed, Feb 25, 2015 at 3:43 PM, Steven Rostedt wrote: > On Wed, 25 Feb 2015 10:20:43 +0100 Ingo Molnar wrote: >> But, if we do that, we can do even better, and also do an >> optimization of the 64-bit entry path as well: we could >> simply mask RAX with 0x3ff and not do a compare. Pad the >> syscall table up to 0x400 (1024) entries and fill in the >> table with sys_ni syscall entries. >> >> This is valid on 64-bit and 32-bit kernels as well, and it >> allows the removal of a compare from the syscall entry >> path, at the cost of a couple of kilobytes of unused >> syscall table. >> >> The downside would be that if we ever grow past 1024 >> syscall entries we'll be in trouble if new userspace calls >> syscall 513 on an old kernel and gets syscall 1. > > What if we test against ~0x3ff and jump to sys_ni if anything is set. > This would still work with new userspace calls on older kernels. That would require a branch insn. The whole idea of masking was merely to avoid that branch. If you need a branch, then you can as well just retain current code. -- 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/