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 S1754061AbdIGHEw (ORCPT <rfc822;w@1wt.eu>);
        Thu, 7 Sep 2017 03:04:52 -0400
Received: from mail-wr0-f171.google.com ([209.85.128.171]:32849 "EHLO
        mail-wr0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1753826AbdIGHEu (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 7 Sep 2017 03:04:50 -0400
X-Google-Smtp-Source: ADKCNb7nShiMTehb/+cWPBqpP0V/7j8YUKnCfXb4duYkPmDIQuvBHcrUiB4x62H2JsCqBOIvLp4/Ww==
Date: Thu, 7 Sep 2017 09:04:46 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>, X86 ML <x86@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Borislav Petkov <bp@alien8.de>, Brian Gerst <brgerst@gmail.com>,
        Andrew Cooper <andrew.cooper3@citrix.com>,
        Juergen Gross <jgross@suse.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        Kees Cook <keescook@chromium.org>
Subject: Re: [RFC 00/17] Pile o' entry stack changes
Message-ID: <20170907070446.uu2tzul45r76kj3o@gmail.com>
References: <cover.1504733277.git.luto@kernel.org>
 <87vakvpj5b.fsf@firstfloor.org>
 <CALCETrXztQ+z+pBDz5Ru6y3e_1uf1xaxkVmOuboDE1uX9vL=hw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALCETrXztQ+z+pBDz5Ru6y3e_1uf1xaxkVmOuboDE1uX9vL=hw@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Andy Lutomirski <luto@kernel.org> wrote:

> On Wed, Sep 6, 2017 at 3:16 PM, Andi Kleen <andi@firstfloor.org> wrote:
> > Andy Lutomirski <luto@kernel.org> writes:
> >>
> >>  - Lots of people (Linus included) have asked to convert the entry
> >>    code to pop registers on exit instead of movqing them off the
> >>    stack.  This makes a bunch of progress in that direction.
> >
> > You should benchmark it on Atoms. Likely it's a regression there
> > because they don't have the special PUSH/POP acceleration.
> 
> I'm not entirely sure this is a worthwhile reason.  Atom will lose a
> few cycles due to POP throughput, but there's a lot less decode
> bandwidth needed and we save a cache line or two.

I think we can also safely assume that Atom will eventually either join the
21st century or die out - mild Atom micro-costs are not a good reason to
complicate the entry code...

Thanks,

	Ingo