> On Feb. 23, 2014, 5:23 p.m., Steve Reinhardt wrote: > > Does LL put the core to sleep in ARM? For Alpha, where LLSC was originally > > implemented, these were two separate things (LL/SC vs. ARM/QUIESCE). While > > x86 doesn't have LL/SC, we do have ARM/QUIESCE in the form of > > MONITOR/MWAIT. Which makes me wonder whether MONITOR/MWAIT would work on a > > system with no caches... > > > > Also, realizing that Alpha almost had an ARM instruction, makes me wonder > > if you might add an ALPHA instruction someday just to reciprocate... > > Andreas Hansson wrote: > 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. > > Andreas Hansson wrote: > Good to go? > > Steve Reinhardt wrote: > 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. > > > > Andreas Hansson wrote: > 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. > > Steve Reinhardt wrote: > 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? > > Andreas Hansson wrote: > 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. - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2163/#review4912 ----------------------------------------------------------- On Feb. 21, 2014, 5:21 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2163/ > ----------------------------------------------------------- > > (Updated Feb. 21, 2014, 5:21 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10074:2b52a708bc9a > --------------------------- > mem: Wakeup sleeping CPUs without caches on LLSC > > For systems without caches, the LLSC code does not get snoops for > wake-ups. We add the LLSC code in the abstract memory to do the job > for us. > > > Diffs > ----- > > src/arch/null/cpu_dummy.hh 2360411a16be > src/mem/abstract_mem.cc 2360411a16be > > Diff: http://reviews.gem5.org/r/2163/diff/ > > > Testing > ------- > > All regressions pass. Previously stalling multi-core boot now proceeds. > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
