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 S966528AbdLSHyv (ORCPT <rfc822;w@1wt.eu>);
        Tue, 19 Dec 2017 02:54:51 -0500
Received: from mail-wm0-f43.google.com ([74.125.82.43]:43189 "EHLO
        mail-wm0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S966514AbdLSHyr (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 19 Dec 2017 02:54:47 -0500
X-Google-Smtp-Source: ACJfBov1MNv25jL2dzh8vMAFtKkgGFRMMh0nocuAHGSTXAfFmZWy1NWfwpsgPXF2C+aTxBTljdXY8w==
Date: Tue, 19 Dec 2017 08:54:43 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Eric Biggers <ebiggers3@gmail.com>
Cc: linux-crypto@vger.kernel.org, Herbert Xu <herbert@gondor.apana.org.au>,
        "David S . Miller" <davem@davemloft.net>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Jussi Kivilinna <jussi.kivilinna@iki.fi>, x86@kernel.org,
        linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
        Eric Biggers <ebiggers@google.com>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH] crypto: x86/twofish-3way - Fix %rbp usage
Message-ID: <20171219075443.tdpt2l72eelhpi7j@gmail.com>
References: <001a113f2cd26f3532055f0f4a79@google.com>
 <20171219004026.170565-1-ebiggers3@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171219004026.170565-1-ebiggers3@gmail.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Eric Biggers <ebiggers3@gmail.com> wrote:

> There may be a small overhead caused by replacing 'xchg REG, REG' with
> the needed sequence 'mov MEM, REG; mov REG, MEM; mov REG, REG' once per
> round.  But, counterintuitively, when I tested "ctr-twofish-3way" on a
> Haswell processor, the new version was actually about 2% faster.
> (Perhaps 'xchg' is not as well optimized as plain moves.)

XCHG has implicit LOCK semantics on all x86 CPUs, so that's not a surprising 
result I think.

Thanks,

	Ingo