The OS uses the Wait For Event (WFE) mechanism to conserve energy, and an access to any locked address has to wake the core up.

Good to go?

Sorry, got distracted ;).  So does that mean in ARM that an LL also effectively acts as an x86 MONITOR?  I'm just trying to map the ARM behavior (ahem, "behaviour") to my understanding of Alpha & x86, to see if this is an ARM-specific thing, and if there's a similar issue for other ISAs.  At the very worst I might ask you to tweak the comment a little to expand your explanation of the scenario--since Alpha doesn't sleep on LLSC, as it stands it's a little confusing if that's all you're familiar with--but other than that the code is fine.

No worries. In essence, a spinlock would include a Wait For Event (WFE) in the loop to conserve energy. The architecture (aarch64) specifies that an event is automatically generated when clearing the exclusive monitor state to wake up processors in WFE (to avoid an explicit DSB/SEV instruction sequence). We could move the event generation (the wakeup in the gem5 world) to the STREX instruction, but the solution adopted in the patch was more straight forward.

The solution looks fine to me.  It's the problem I'm trying to understand :).

I'd say please update the comment to specifically mention ARM and WFE and then I'm fine with shipping it.  It seems like there's no harm in sending spurious wakeups in other ISAs, but is it worth making this #ifdef ARM just in case?

You highlight an important problem. I'd like to make sure we build the memory system once, not per ISA, and just put it in libmem.a and use it throughout. Currently there are some spurious ISA-dependent bits in Ruby, but in general these could be abstracted as system-level constants. I would really not like to add any additional ISA-specific bits. We can either live without the ifdef, or potentially go for the STREX option instead.

I agree on the desirability of avoiding ISA dependencies in the memory system.  I just glanced at the wakeup() implementations for SimpleCPU and O3, and they both are no-ops if the thread is not suspended.  Thus it seems reasonable  to me that we could leave this wakeup in place and it will have no ill effects on other ISAs where it is not needed.  My only concern now is that there's enough information in the comment such that, if this assumption is wrong and someone tracks the problem back to this call site, it will be obvious to them what is going on.