Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1133082imm; Fri, 28 Sep 2018 12:35:48 -0700 (PDT) X-Google-Smtp-Source: ACcGV63FGsp1i4NM0DzGc3R2loD8usYXfmgjUlOxiROj2ZVv37FewMm5CZYq/cNnKaLxU/TX5dmF X-Received: by 2002:a63:1806:: with SMTP id y6-v6mr62562pgl.187.1538163348070; Fri, 28 Sep 2018 12:35:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538163348; cv=none; d=google.com; s=arc-20160816; b=IkgN5s9wdecQ2SH/NssHjG8N/aWVQVfUEYI15R6cJx4VNrIBFv2WrXjOeDrPIoSYMi xGTnjVd4rd3rCrBDHwYNXYUeHmh4YqzOdLxf+CWiB/3nzzvnHATZ3Xi1P22RsqSn4Ilm jA2QYqbTMs9fHGtEV1XycETp3NdbSn2yAdfI6Hh+Mg2t2DqNuia9R0chugEQIBfU4uf4 N2uA+M+O/HGe9nV5JdmR0K1LLeFnbGXbxGUh4k6fmepuCitmATA10jyALhkVUDb3X1S4 K8i3uso0gEJ1Mb1T2mDZ9v6gEep+rwfOz3UBmkJQxwZButkc1C7B2m0zW39JTAgGLvUk l9Wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=prAqz+t3zSr5HjOS9lu7uq2+k/N8PRuhPquSX1sZ3m8=; b=MPuELJk7FH2RNELc+VC3+yO+b/0cw6L3OnCWdhnMwhXR2xE2Q407AgvbILXOm6ZjxF oW1P49dSgbUzzhpU2J9bglB+jj4s0a37NjFrakAVMU9evIbMgdm6evuTwOW7H0bGvfEw gM5rbs3CAjwgJyfJdQ6OqC0czyCzYLQVwsjviTeriJLsdxbC/3UzT9+GUSegq2t5VELd WicdHUCOjydKTo7KzZAmxa6noGoICLQ5TOqskqiE2OobpAwZ+aEkFDbiWy+j4t+IJ8rD KQWviZflkcRoBygJpcTB1OCbDjUqGU9CW72INUxW3T0K0mHeupBk1DpjpnQXXpw7amZv /low== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 5-v6si6074465pfa.305.2018.09.28.12.35.33; Fri, 28 Sep 2018 12:35:48 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726727AbeI2B71 (ORCPT + 99 others); Fri, 28 Sep 2018 21:59:27 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:55059 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726304AbeI2B71 (ORCPT ); Fri, 28 Sep 2018 21:59:27 -0400 Received: from p5492e4c1.dip0.t-ipconnect.de ([84.146.228.193] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1g5yWg-0004a4-DX; Fri, 28 Sep 2018 21:34:10 +0200 Date: Fri, 28 Sep 2018 21:34:09 +0200 (CEST) From: Thomas Gleixner To: Sebastian Andrzej Siewior cc: Kurt Kanzenbach , Will Deacon , linux-kernel@vger.kernel.org, Daniel Wagner , Peter Zijlstra , x86@kernel.org, Linus Torvalds , "H. Peter Anvin" , Boqun Feng , "Paul E. McKenney" , Mark Rutland Subject: Re: [Problem] Cache line starvation In-Reply-To: <20180928192630.nvwlwlgswde2fpbq@linutronix.de> Message-ID: References: <20180921120226.6xjgr4oiho22ex75@linutronix.de> <20180926125301.GE2979@brain-police> <20180927142547.ucgh5elb7pxs46dq@linutronix.de> <20180927144127.qdkem4juhztxdkdb@linutronix.de> <20180928192630.nvwlwlgswde2fpbq@linutronix.de> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Sep 2018, Sebastian Andrzej Siewior wrote: > On 2018-09-27 16:47:47 [+0200], Thomas Gleixner wrote: > > I wonder if it's just the store on the stack which makes it work. I've seen > > that when instrumenting x86. When the careful instrumentation just stayed > > in registers it failed. Once it was too much and stack got involved it > > vanished away. > > Added two load/stores into wait_task_inactive() and it still triggers > (on the core2duo). So it was some interaction with rdtsc() which got stored on stack. Heisenbugs are lovely. Thanks, tglx