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 S1751599AbdLSRgF (ORCPT <rfc822;w@1wt.eu>);
        Tue, 19 Dec 2017 12:36:05 -0500
Received: from mail-wm0-f52.google.com ([74.125.82.52]:44580 "EHLO
        mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750723AbdLSRfh (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 19 Dec 2017 12:35:37 -0500
X-Google-Smtp-Source: ACJfBoviN4fUngHX+jHUWS7of23NzRf8bpvlrxDtz8jSoKIcSZjICzOuMxQqg5OSaEyHbsKmsP+5HA==
Date: Tue, 19 Dec 2017 18:35:33 +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: <20171219173533.25evvqns4tlxztzj@gmail.com>
References: <001a113f2cd26f3532055f0f4a79@google.com>
 <20171219004026.170565-1-ebiggers3@gmail.com>
 <20171219075443.tdpt2l72eelhpi7j@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171219075443.tdpt2l72eelhpi7j@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


* Ingo Molnar <mingo@kernel.org> wrote:

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

Correction: I think XCHG only implies LOCK if there's a memory operand involved - 
register-register XCHG should not imply any barriers.

So the result is indeed unintuitive.

Thanks,

	Ingo