From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752817AbbCPJoj (ORCPT <rfc822;w@1wt.eu>);
	Mon, 16 Mar 2015 05:44:39 -0400
Received: from mail-we0-f176.google.com ([74.125.82.176]:35521 "EHLO
	mail-we0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750862AbbCPJoe (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Mar 2015 05:44:34 -0400
Date: Mon, 16 Mar 2015 10:44:28 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>,
        Andy Lutomirski <luto@amacapital.net>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Steven Rostedt <rostedt@goodmis.org>, Borislav Petkov <bp@alien8.de>,
        "H. Peter Anvin" <hpa@zytor.com>, Oleg Nesterov <oleg@redhat.com>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Alexei Starovoitov <ast@plumgrid.com>, Will Drewry <wad@chromium.org>,
        Kees Cook <keescook@chromium.org>, X86 ML <x86@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/4] x86: save user rsp in pt_regs->sp on SYSCALL64
 fastpath
Message-ID: <20150316094428.GA32738@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>
 <CAK1hOcMTRhO3hhqD0Ft6qJ-NYn9uZ7tcTKxJB1=nRR-3fkbYEw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAK1hOcMTRhO3hhqD0Ft6qJ-NYn9uZ7tcTKxJB1=nRR-3fkbYEw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Denys Vlasenko <vda.linux@googlemail.com> wrote:

> > - 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.

Ok, so I've applied this particular cleanup, in the hope that we can 
recover those cycles on the now cleaner base.

If that doesn't work out then we can still re-introduce this 
complication and see its maintainability in isolation, on a clean 
base.

Thanks,

	Ingo