config: allow more than 3GB of memory for x86 simulations
Review Request #2148 - Created Jan. 17, 2014 and submitted
| Information | |
|---|---|
| Nilay Vaish | |
| gem5 | |
| default | |
| Reviewers | |
| Default | |
Changeset 10015:f67896fae8ec --------------------------- config: allow more than 3GB of memory for x86 simulations This patch edits the configuration files so that x86 simulations can have more than 3GB of memory. It also corrects a bug in the MemConfig.py script.
Issue Summary
2
2
0
0
| Description | From | Last Updated | Status |
|---|---|---|---|
| I'm not a massive fan of this implicit splitting. Is there no sensible way we can make this more explicit, ... | Andreas Hansson | Jan. 20, 2014, 12:24 a.m. | Open |
| Implicit assumptions here as well that would be good to avoid. | Andreas Hansson | Jan. 20, 2014, 12:24 a.m. | Open |
Posted (Jan. 20, 2014, 12:25 a.m.)
-
configs/common/FSConfig.py (Diff revision 1) -
I'm not a massive fan of this implicit splitting. Is there no sensible way we can make this more explicit, for example by forcing the user to specify a (comma-separated) list of sizes?
-
configs/common/FSConfig.py (Diff revision 1) -
Implicit assumptions here as well that would be good to avoid.
Posted (Jan. 20, 2014, 8:03 a.m.)
Looking at this briefly, I'd say I'm with Andreas in spirit but with Nilay in practice. The implicit split is ugly, but that's just the way the PC platform works, for purely historical reasons, and it's not ever going to change. I don't see any benefit in exposing these warts to users if we don't have to. Aesthetically, it might be nice to make a better separation between the "generic" x86 architecture and the "PC platform", as this wart is clearly located in the latter. However, I doubt anyone would ever build a non-PC x86 platform, so I doubt the effort would have any non-aesthetic value. That said, the code really does need some comments explaining what's going on.
-
configs/common/FSConfig.py (Diff revision 1) -
It's more direct to do: mem_size = convert.toMemorySize(mdesc.mem())
-
configs/common/FSConfig.py (Diff revision 1) -
I also think it would be clearer to pu the 3GB value in a variable and reuse it rather than calculating it twice. You could even generate it with: convert.toMemorySize('3GB') which would be clearer and more consistent -
configs/common/FSConfig.py (Diff revision 1) -
Another comment would be nice; perhaps also an assertion that len(self.mem_ranges) <= 2
Review request changed
Updated (Jan. 20, 2014, 11:43 a.m.)
Description: |
|
||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Diff: |
Revision 2 (+29 -8) |
Looks good to me, thanks! Let's see what Andreas thinks...
Posted (Jan. 21, 2014, 1:27 a.m.)
It looks much better with the comments. One potential concern is that we consider each memory range as a separate multi-channel DRAM controller. Hence, when we split 4 GB into 3 GB + 1 GB, we now create a (potentially multi-channel) controller per range. If the user says 4 channel DDR3, we now have 8 channels of DDR3. I don't know what is sensible to do here, but perhaps this solutions needs to be a bit more elaborate, and involve an AddrMapper one way or another?
