> On April 24, 2015, 2:41 p.m., Mitch Hayenga wrote: > > In general this seems fine. > > > > Normally I’d consider it "user error" to use a m5 quiesce instruction with > > a 0 cycle delay parameter normally though. Is this x86 improperly using > > quiesce instructions? How did this case come up? > > > > Thanks. > > Emilio Castillo wrote: > Just booted an unmodified linux kernel in x86 (obtained at > http://www.cs.utexas.edu/~cart/parsec_m5/) and took a checkpoint after it > booted up. > > When restoring the checkpoint with the O3 cpu, after a few seconds in the > bash it hangs. Running again with the --debug-flags=Exec showed that the OS > was doing a quiesce with 0 ns.
Hey guys, I tracked down the source of this. The kernel in question is actually a custom modified kernel (x86_64-vmlinux-2.6.28.4-smp) that was built with very old gem5 patches applied. Those gem5 patches used pseudo-instructions to calibrate delay loops during kernel boot to speed things up. However, as things have changed in gem5, this calibration is no longer needed, and just leaves the delay with the default value, 0. As a result, the quiesceNs pseudo-instruction is called from kernel delay loops with a parameter of 0. Rebuilding the Linux kernel without these patches would eliminate this issue. However, Emilio's change here not only fixes this strange use, but is also the correct way to handle this: gem5 changeset 10341 tagged the x86 quiesce instructions as IsQuiesce, which causes the O3 CPU core's fetch stage to wait for an EndQuiesceEvent before continuing fetch. Thus, EVERY time that an IsQuiesce instruction is executed, the EndQuiesceEvent must be rescheduled to keep the CPU core from halting execution. - Joel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2740/#review6073 ----------------------------------------------------------- On April 16, 2015, 4:48 p.m., Emilio Castillo wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2740/ > ----------------------------------------------------------- > > (Updated April 16, 2015, 4:48 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > The O3CPU blocks the Fetch when it sees a quiesce instruction (IsQuiesce > flag). > When the inst. is executed, a quiesce event is created to reactivate the > context > and unblock the Fetch. > > If the quiesceNs or quiesceCycles are called with a value of 0, the > QuiesceEvent will not be created and the Fetch stage will remain blocked. > > > Diffs > ----- > > src/sim/pseudo_inst.cc 8a7285d6197e > > Diff: http://reviews.gem5.org/r/2740/diff/ > > > Testing > ------- > > Boot a Linux Kernel with X86, Out of Order & Ruby. > When the kernel boots and calls the shell, quiesce instructions with 0ns are > executed deadlocking the O3 cpu. > > > Thanks, > > Emilio Castillo > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
