Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752954AbbBYOnQ (ORCPT ); Wed, 25 Feb 2015 09:43:16 -0500 Received: from smtprelay0216.hostedemail.com ([216.40.44.216]:56576 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751866AbbBYOnP (ORCPT ); Wed, 25 Feb 2015 09:43:15 -0500 X-Session-Marker: 6E657665747340676F6F646D69732E6F7267 X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,rostedt@goodmis.org,:::::::::::::::::::::::::,RULES_HIT:41:355:379:421:541:599:800:960:973:988:989:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1540:1593:1594:1711:1730:1747:1777:1792:2393:2553:2559:2562:2740:3138:3139:3140:3141:3142:3352:3622:3865:3866:3867:3868:3870:3871:3872:3874:4250:5007:6261:6742:7875:9389:10004:10400:10848:10967:11232:11658:11914:12296:12517:12519:12740:13069:13311:13357:21080,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0 X-HE-Tag: rat06_393dec3ce3753 X-Filterd-Recvd-Size: 2258 Date: Wed, 25 Feb 2015 09:43:12 -0500 From: Steven Rostedt To: Ingo Molnar Cc: "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" Subject: Re: [PATCH 1/4] x86: entry.S: tidy up several suboptimal insns Message-ID: <20150225094312.2cfff453@gandalf.local.home> In-Reply-To: <20150225092043.GB16165@gmail.com> References: <1424803895-4420-1-git-send-email-dvlasenk@redhat.com> <54ED00B5.3020203@zytor.com> <20150225092043.GB16165@gmail.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1112 Lines: 29 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. -- Steve -- 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/