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 S932939AbcFCNjb (ORCPT <rfc822;w@1wt.eu>);
	Fri, 3 Jun 2016 09:39:31 -0400
Received: from bombadil.infradead.org ([198.137.202.9]:53519 "EHLO
	bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932538AbcFCNj3 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 3 Jun 2016 09:39:29 -0400
Date: Fri, 3 Jun 2016 15:39:20 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>, Ingo Molnar <mingo@kernel.org>,
        Dexuan Cui <decui@microsoft.com>,
        "linux-x86_64@vger.kernel.org" <linux-x86_64@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        David Howells <dhowells@redhat.com>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?
Message-ID: <20160603133920.GA3913@twins.programming.kicks-ass.net>
References: <BLUPR03MB1410A48DDA4C0A4902A8E163BFBD0@BLUPR03MB1410.namprd03.prod.outlook.com>
 <20160303152739.GA16303@gmail.com>
 <20160303153453.GR6356@twins.programming.kicks-ass.net>
 <20160303203414-mutt-send-email-mst@redhat.com>
 <66C0F0F8-5D2C-47DB-8C7A-EF8A15F263DB@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <66C0F0F8-5D2C-47DB-8C7A-EF8A15F263DB@zytor.com>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Mar 03, 2016 at 11:05:43AM -0800, H. Peter Anvin wrote:
> >> latest version here:
> >> 
> >>   lkml.kernel.org/r/1453921746-16178-1-git-send-email-mst@redhat.comZ
> >
> >It's ready as far as I am concerned.
> >Basically we are just waiting for ack from hpa.
> 
> And I'm still discussing this with the hardware people.  It seems we
> can do this for *most* things, but not all; the question is where
> exactly we need to do something different.

Anything on this?