Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2125926imm; Thu, 27 Sep 2018 07:50:07 -0700 (PDT) X-Google-Smtp-Source: ACcGV62wcVI5s7dB3S6h8JyYs9JetZNeP+V2KoRM6jOWoNsvnpMrPp4t0a6NEln6D/fKB07WHNwR X-Received: by 2002:a65:4289:: with SMTP id j9-v6mr10769689pgp.284.1538059807449; Thu, 27 Sep 2018 07:50:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538059807; cv=none; d=google.com; s=arc-20160816; b=o6qvG/tJPvfwUIwvU8HhYNBst1mcbKmI9/4abDQiLS1ZU0fdVccH/7s8mw3iO8wsLN 1N+Swh6yG3j17ObhHc+Cve4miMIpTfSDXjWLw0VZgzAgUsljuTWy4TQglaz2GfwKgRL9 gjwSw6F0s7M8ik1yTppOUmoPW98UWjUwF4gOxbhrJle1V8XA+vvu9sRc0PJrgkth5skq 0OV+VgOQlcwBZXJriEbVPkVnGB/7cJBVdS9NPS8AN++BzgOrXvZ18evc+b5iCiH9hMWm hcOZXlgwqC9G8AeXYRP1TF6kYEW4mVl3WY2G40ZoVBqSU+jd4kA/H8Avw0Z9hpbFGPpu NDJw== 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=sMu80xvE0lDc2bKmhbq61lJqG6H1zF+0lrl8s5AR2nw=; b=Hx9WpC2FqWJ2tEjgrfW1J/Uu+A9ftjXg6+YmRzxRSZEhBBy+8oJprirxfbnUvwa7S2 aR4ywzNFqqWCwgMx6x5bMC3ozSC6VvbYGndB5J6nQgD3DzPQ6X6xO8NROaVl/WV4JDkI X2qPRkEa/zD2MAbaccQV9uQ0nirjDeFyZmptr+MH2mc8gJP7kbDlv5DbD6lFL+TlkTBB VajhIPGpVPIZS/EYY2ckp4WYTLdyqehFYbo1Isf2XwN2Wwyh9o4PZaN5+GovW+Jzj7AU N13GxtTb8lMgDXEcmy9euvQVuijQ4dlGuhyJ8h+/TLDpYQ0lwgj6r25Ci/uJcenB635E h61Q== 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 d10-v6si1970689pgg.330.2018.09.27.07.49.51; Thu, 27 Sep 2018 07:50:07 -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 S1727826AbeI0VG1 (ORCPT + 99 others); Thu, 27 Sep 2018 17:06:27 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:52170 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727199AbeI0VG1 (ORCPT ); Thu, 27 Sep 2018 17:06: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 1g5Xa0-0005TK-E1; Thu, 27 Sep 2018 16:47:48 +0200 Date: Thu, 27 Sep 2018 16:47:47 +0200 (CEST) From: Thomas Gleixner To: Kurt Kanzenbach cc: Will Deacon , Sebastian Andrzej Siewior , 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: <20180927144127.qdkem4juhztxdkdb@linutronix.de> Message-ID: References: <20180921120226.6xjgr4oiho22ex75@linutronix.de> <20180926125301.GE2979@brain-police> <20180927142547.ucgh5elb7pxs46dq@linutronix.de> <20180927144127.qdkem4juhztxdkdb@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 Thu, 27 Sep 2018, Kurt Kanzenbach wrote: > On Thu, Sep 27, 2018 at 04:25:47PM +0200, Kurt Kanzenbach wrote: > > However, the issue still triggers fine. With stress-ng we're able to > > generate latency in millisecond range. The only workaround we've found > > so far is to add a "delay" in cpu_relax(). > > It might interesting for you, how we added the delay. We've used: > > static inline void cpu_relax(void) > { > volatile int i = 0; > > asm volatile("yield" ::: "memory"); > while (i++ <= 1000); > } > > Of course it's not efficient, but it works. 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. Thanks, tglx