On Friday 19 June 2015 03:29 PM, Will Deacon wrote:
> On Fri, Jun 19, 2015 at 10:55:26AM +0100, Vineet Gupta wrote:
>> > A quad core SMP build could get into hardware livelock with concurrent
>> > LLOCK/SCOND. Workaround that by adding a PREFETCHW which is serialized by
>> > SCU (System Coherency Unit). It brings the cache line in Exclusive state
>> > and makes others invalidate their lines. This gives enough time for
>> > winner to complete the LLOCK/SCOND, before others can get the line back.
>> >
>> > Cc: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
>> > Signed-off-by: Vineet Gupta <vgupta@xxxxxxxxxxxx>
>> > ---
>> > arch/arc/include/asm/atomic.h | 14 ++++++++++++--
>> > 1 file changed, 12 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arc/include/asm/atomic.h b/arch/arc/include/asm/atomic.h
>> > index 20b7dc17979e..03484cb4d16d 100644
>> > --- a/arch/arc/include/asm/atomic.h
>> > +++ b/arch/arc/include/asm/atomic.h
>> > @@ -23,13 +23,21 @@
>> >
>> > #define atomic_set(v, i) (((v)->counter) = (i))
>> >
>> > +#ifdef CONFIG_ISA_ARCV2
>> > +#define PREFETCHW " prefetchw [%1] \n"
>> > +#else
>> > +#define PREFETCHW
>> > +#endif
>> > +
>> > #define ATOMIC_OP(op, c_op, asm_op) \
>> > static inline void atomic_##op(int i, atomic_t *v) \
>> > { \
>> > unsigned int temp; \
>> > \
>> > __asm__ __volatile__( \
>> > - "1: llock %0, [%1] \n" \
>> > + "1: \n" \
>> > + PREFETCHW \
>> > + " llock %0, [%1] \n" \
>> > " " #asm_op " %0, %0, %2 \n" \
>> > " scond %0, [%1] \n" \
>> > " bnz 1b \n" \
> Curious, but are you *sure* the prefetch should be *inside* the loop?
> On most ll/sc architectures, that's a livelock waiting to happen because
> you ping-pong the cache-line around in exclusive state.
Indeed, the prefetchw inside the loop seems dubious, but this is what broke the
h/w livelock when we were playing with multibench last year and what i was told to
do by h/w folks. Let me go check once again !
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
