Re: [Problem] Cache line starvation

From: Thomas Gleixner <tglx@linutronix.de>
To: Kurt Kanzenbach <kurt.kanzenbach@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	linux-kernel@vger.kernel.org,
	Daniel Wagner <daniel.wagner@siemens.com>,
	Peter Zijlstra <peterz@infradead.org>,
	x86@kernel.org, Linus Torvalds <torvalds@linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Mark Rutland <mark.rutland@arm.com>
Subject: Re: [Problem] Cache line starvation
Date: Thu, 27 Sep 2018 16:47:47 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1809271644120.8118@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20180927144127.qdkem4juhztxdkdb@linutronix.de>

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