Extend physical memory beyond 4GB

Information
Submitter:	Nilay Vaish
Repository:	gem5
Branch:	default
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

Description

Changeset 8852:3c033ec380b5
---------------------------
Extend physical memory beyond 4GB
The patch adds a list of address ranges to the physical memory instead of
having a single address range. It has been tested with X86 architecture so
far.

Testing Done

Issue Summary

Description	From	Last Updated	Status
the default shouldn't change.	Ali Saidi	Feb. 16, 2012, 2:37 a.m.	Open
Addr('3GB')? that constant is not reasonable	Ali Saidi	Feb. 16, 2012, 2:37 a.m.	Open
I believe that real x86 systems map the entire space and then re-map the 3-4GB range somewhere else.	Ali Saidi	Feb. 16, 2012, 2:37 a.m.	Open
This seems like a kludge	Ali Saidi	Feb. 16, 2012, 2:37 a.m.	Open
this shouldn't be commented out, it should be fixed.	Ali Saidi	Feb. 16, 2012, 2:37 a.m.	Open

Could you provide a bit more background to what system this intends to capture and where/how/when this is needed?

My initial feeling is that we need to think carefully about this, and design the functionality slightly differently and make sure we can support: 1) multiple distributed memories in the system (without requirements on size, location, etC), 2) a non-contiguous address map (either a global one, or per master), and do so without any magic constants etc.

I've been working on a patch that wraps all the memories in the system in a "memoryspace" that can fill the role of the current system.physmem structure, i.e. a global chunk where you can find the total size and the valid address ranges. This non-strucural collection of the memory system would simply get populated when we instantiate the real memories in the system (i.e. PhysMem etc). The individual memories are, until now, all contiguous, but you could have as many of them as you want and thus chop up the address map.

Nilay Vaish Feb. 16, 2012, 2:02 a.m. (Feb. 16, 2012, 2:02 a.m.)

Andreas, for the x86 architecture, the addresses from 0xC0000000 to 0xFFFFFFFF are reserved for
devices. Hence the physical memory can be at most 3GB in size because of the assumption that it
needs to continuous (as you mentioned). While trying to remove this limit, I thought there are
two possible choices. One is that a single physical memory can cater to multiple different
address ranges. The second choice is to have multiple physical memories in the system. In order to
have multiple different physical memories, I would have to figure out how to connect them correctly.
So, instead I decided on having a single physical memory that can support multiple address ranges.

Does the choice really matter i.e. aren't the two approaches equivalent?

Ali Saidi Feb. 16, 2012, 2:38 a.m. (Feb. 16, 2012, 2:38 a.m.)

I meant to edit my review, not publish it, so I'l comment here instead. I think here is a difference because if you want to have memories with different characteristics you can't with the current mechanism.

Nilay Vaish Feb. 17, 2012, 2:28 a.m. (Feb. 17, 2012, 2:28 a.m.)

I agree that having multiple physical memories is a better solution. Andreas, how soon
will you be able to finish your proposed patch? Do you need any help on this?

Andreas Hansson Feb. 20, 2012, 6:55 p.m. (Feb. 20, 2012, 6:55 p.m.)

The "memory space", a.k.a. "no more physmem" patch is probably a few weeks away. There are a bunch of patches in our queue that we need to get out first, but once that is sorted it shouldn't be a problem.

I'll let you know if any help is needed.

Andreas Hansson March 21, 2012, 9:31 a.m. (March 21, 2012, 9:31 a.m.)

The distributed-memory patch has arrived! Hopefully it solves this problem Nilay, and we can close this one.

configs/common/Benchmarks.py (Diff revision 1)

the default shouldn't change.

Show all issues

configs/common/FSConfig.py (Diff revision 1)

Addr('3GB')? that constant is not reasonable

Show all issues

configs/common/FSConfig.py (Diff revision 1)

I believe that real x86 systems map the entire space and then re-map the 3-4GB range somewhere else.

Show all issues

configs/ruby/MESI_CMP_directory.py (Diff revision 1)

This seems like a kludge

Show all issues

src/mem/physical.cc (Diff revision 1)

this shouldn't be commented out, it should be fixed.

Show all issues

You have a pending review.

Review Board 2.0.15

This change has been discarded.

Screenshots

Files

Issue Summary

Status: Discarded