cpu: o3: Fetch stage updates for hw threads priority list
Review Request #2855 - Created May 28, 2015 and updated
| Information | |
|---|---|
| Alexandru Dutu | |
| gem5 | |
| default | |
| Reviewers | |
| Default | |
Changeset 10866:616c230e9722 --------------------------- cpu: o3: Fetch stage updates for hw threads priority list This patch makes sure the priority_list in the fetch stage is kept in sync with suspendContext and activateContext calls.
Quick regressions passed for all ISAs.
Issue Summary
| Description | From | Last Updated | Status |
|---|---|---|---|
| Do you need to check the thread state when you initialize the priority list? | Andreas Sandberg | June 22, 2015, 3:19 p.m. | Open |
-
src/cpu/o3/fetch_impl.hh (Diff revision 1) -
This is doing almost exactly the same thing as resetStage(). Is there any way you could refactor it to remove this duplication?
Change Summary:
Refactored startupStage and resetStage.
Description: |
|
||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Diff: |
Revision 2 (+17 -18) |
Hmm, I think I'm still a bit confused about startupStage() and resetStage(). It seems to me that the only reason you're initializing the priority list in resetStage() is because it is called from takeOverFrom(). This call flow seems a bit counterintuitive to me, in particular calling startupStage() from resetStage() seems backwards.
Wouldn't it make more sense to keep all the initialization, except for the priority list, in resetStage() and setup the priority list in takeOverFrom()? That'd make it easier to follow (I'd expect startup to call reset) what's going on here.
-
src/cpu/o3/fetch_impl.hh (Diff revision 2) -
Do you need to check the thread state when you initialize the priority list?