Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v10 6/6] x86/split_lock: Enable split lock detection by kernel parameter
Date:   Thu, 12 Dec 2019 08:02:13 -0800
Message-Id: <A1D491D5-0079-487C-A834-FB504EDD8782@amacapital.net>
References: <20191212130421.GX2827@hirez.programming.kicks-ass.net>
Cc:     David Laight <David.Laight@aculab.com>,
        "Luck, Tony" <tony.luck@intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        "Yu, Fenghua" <fenghua.yu@intel.com>,
        Ingo Molnar <mingo@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        H Peter Anvin <hpa@zytor.com>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        x86 <x86@kernel.org>, Will Deacon <will@kernel.org>
In-Reply-To: <20191212130421.GX2827@hirez.programming.kicks-ass.net>
To:     Peter Zijlstra <peterz@infradead.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Dec 12, 2019, at 5:04 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>=20
> Waiting for a store-buffer drain is *expensive*.
>=20
> Try timing:
>=20
>    LOCK INC (ptr);
>=20
> vs
>=20
>    LOCK INC (ptr);
>    MFENCE
>=20
> My guess is the second one *far* more expensive. MFENCE drains (and waits
> for completion thereof) the store-buffer -- it must since it fences
> against non-coherent stuff.

MFENCE also implies LFENCE, and LFENCE is fairly slow despite having no arch=
itectural semantics other than blocking speculative execution. AFAICT, in th=
e absence of side channels timing oddities, there is no code whatsoever that=
 would be correct with LFENCE but incorrect without it. =E2=80=9CSerializati=
on=E2=80=9D is, to some extent, a weaker example of this =E2=80=94 MOV to CR=
2 is *much* slower than MFENCE or LOCK despite the fact that, as far as the m=
emory model is concerned, it doesn=E2=80=99t do a whole lot more.

So the fact that draining some buffer or stalling some superscalar thingy is=
 expensive doesn=E2=80=99t necessarily mean that the lack of said draining i=
s observable in the memory model.

(LFENCE before RDTSC counts as =E2=80=9Ctiming=E2=80=9D here.)