From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751777AbbCJNuk (ORCPT ); Tue, 10 Mar 2015 09:50:40 -0400 Received: from mail-qc0-f172.google.com ([209.85.216.172]:39633 "EHLO mail-qc0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751057AbbCJNuj (ORCPT ); Tue, 10 Mar 2015 09:50:39 -0400 MIME-Version: 1.0 In-Reply-To: <20150310132147.GB26185@gmail.com> References: <1425926364-9526-1-git-send-email-dvlasenk@redhat.com> <1425926364-9526-4-git-send-email-dvlasenk@redhat.com> <20150310125151.GB21686@gmail.com> <54FEEF0D.5080505@redhat.com> <20150310132147.GB26185@gmail.com> From: Denys Vlasenko Date: Tue, 10 Mar 2015 14:50:18 +0100 Message-ID: Subject: Re: [PATCH 3/4] x86: save user rsp in pt_regs->sp on SYSCALL64 fastpath To: Ingo Molnar Cc: Denys Vlasenko , Andy Lutomirski , Linus Torvalds , Steven Rostedt , Borislav Petkov , "H. Peter Anvin" , Oleg Nesterov , Frederic Weisbecker , Alexei Starovoitov , Will Drewry , Kees Cook , X86 ML , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 10, 2015 at 2:21 PM, Ingo Molnar wrote: >> Since this patch does add two extra MOVs, >> I did benchmark these patches. They add exactly one cycle >> to system call code path on my Sandy Bridge CPU. > > Hm, but that's the wrong direction, we should try to make it faster, > and to clean it up As you know, goals of "faster" and "cleaner" are often mutually exclusive. C'est la vie :( entry.S seem to lean towards "faster" to the extent where it became a tangled maze of obscure optimizations. Such as the mysterious, and not at all obvious existence of 8 byte "safety padding" at the top of the 32-bit kernel stack. Before Andy stumbled into it, it was not at all obvious that it is even there. I had to write a test patch to verify it. There is a long-standing latent bug in the code where this padding is not accounted for. > - but making it slower without really good reasons isn't good. The thinking here is that cleaning up entry.S is a good reason. We won't do anything which would slow it down by, say, 5%, but one cycle may be considered acceptable loss.