o3: Create quiesce Events with 0ns or 0 cycles

Information
Submitter:	Emilio Castillo
Repository:	gem5
Branch:
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

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.

Testing Done

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.

Summary:

-	Create quiesce Events with 0ns or 0 cycles
+	o3: Create quiesce Events with 0ns or 0 cycles

Description:

~		The O3CPU blocks the Fetch when it sees a quiesce instruction (IsQuiesce) flag.
	~	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.

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 April 24, 2015, 8 a.m. (April 24, 2015, 8 a.m.)

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.

Joel Hestness Aug. 25, 2015, 1:36 p.m. (Aug. 25, 2015, 1:36 p.m.)

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.

Ship It!

You have a pending review.

Review Board 2.0.15

This change has been marked as submitted.

Screenshots

Files

Summary:

Description:

Status: Closed (submitted)