[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150610110234.GH3644@twins.programming.kicks-ass.net>
Date: Wed, 10 Jun 2015 13:02:34 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Vineet Gupta <Vineet.Gupta1@...opsys.com>
Cc: "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"arnd@...db.de" <arnd@...db.de>,
"arc-linux-dev@...opsys.com" <arc-linux-dev@...opsys.com>
Subject: Re: [PATCH 22/28] ARCv2: STAR 9000837815 workaround hardware
exclusive transactions livelock
On Wed, Jun 10, 2015 at 10:01:01AM +0000, Vineet Gupta wrote:
> OK - I need some more time to rehash the exact details with our
> hardware folks. But AFAIKR, this was hardware livelock in llock/scond
> when 2 cores were doing r-m-w to two different words in the same cache
> line - adding prefetchw (prefetch with a write intent) would get the
> line in exclusive state and break the livelock.
>
> The test itself was one from EEMBC Multibench but I'll have to look it
> up.
>
> Wasn't there something similar in ARM world too - they have some sort
> of snoop-delayed exclusive handling in hardware to mitigate something
> similar although as Will later remarked it involved llock/scond with
> vanilla ld/st to same line/word ?
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/254142.html
Cute, I was not aware of that.
Sounds reasonable (unfortunate but understandable). Speaking as someone
who at times does full arch sweeps on code like this it really helps
understanding if such things are explained a wee bit better than not at
all :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists