Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756408AbdIIS0c (ORCPT ); Sat, 9 Sep 2017 14:26:32 -0400 Received: from mail-it0-f43.google.com ([209.85.214.43]:37417 "EHLO mail-it0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755208AbdIIS03 (ORCPT ); Sat, 9 Sep 2017 14:26:29 -0400 X-Google-Smtp-Source: AOwi7QC+QRlxgEOgc1cOnxyL1rdK1x9cQl5MfNjMWkB0iDhvJYl8LzzMsEsa/HT7sWXlbUHQVYEykCeEtbn8EVe6YOM= MIME-Version: 1.0 In-Reply-To: <20170909181445.GA281@x4> References: <20170909133745.GA289@x4> <20170909133954.GB289@x4> <20170909140700.bp7jonmp7etlb7ov@pd.tnic> <20170909142014.GC289@x4> <20170909143335.ja2iwjsbeyfxz4ez@pd.tnic> <20170909144350.GA290@x4> <20170909163225.GA290@x4> <20170909170537.6xmxtzwripplhhwi@pd.tnic> <20170909172352.GA290@x4> <20170909173633.4ttfk7maooxkcwum@pd.tnic> <20170909181445.GA281@x4> From: Linus Torvalds Date: Sat, 9 Sep 2017 11:26:27 -0700 X-Google-Sender-Auth: 9ES7f0f8-MSZCyx8WG9tclFLiNw Message-ID: Subject: Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf To: Markus Trippelsdorf Cc: Borislav Petkov , Andy Lutomirski , Ingo Molnar , Thomas Gleixner , Peter Zijlstra , LKML , Ingo Molnar , Tom Lendacky Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v89IQaj7007703 Content-Length: 952 Lines: 27 On Sat, Sep 9, 2017 at 11:14 AM, Markus Trippelsdorf wrote: > > I think the issue gets fixed by: > > # wrmsr -a 0xc0010015 0x1000018 > > Setting bit 3 of the Hardware Configuration Register to 1. > > Quote for the docs: > »TlbCacheDis: cacheable memory disable. Read-write. 0=Enables performance optimization that > assumes PML4, PDP, PDE, and PTE entries are in cacheable WB-DRAM Uhhuh. The page directories should *definitely* always be in cacheable memory, so it should be ok for that bit to be 0, and it's possible that setting it to 1 will seriously screw up performance. But the fact that that fixes it for you does indicate that it's not just a stale TLB entry or something, it really is some CPU using page tables after they have been free'd and been re-allocated to something else (and *then* they may point to garbage). So I do think it's a sign that we definitely need that IPI for you. Linus