ruby: Size the MI_example directory to cover all phys mem

Information
Submitter:	Andreas Sandberg
Repository:	gem5
Branch:	default
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

Description

Changeset 11576:653c0ded0b9f
---------------------------
ruby: Size the MI_example directory to cover all phys mem

The directories in Ruby currently assume that memory starts at zero
and spans to the total memory size. This is not true for a lot of
systems. As a workaround, make the directory cover all memory from 0
to the end of the last physical memory in the memory map.

Change-Id: I350f4076c46a603a85df317ebbb341dd426feb7d
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>

Testing Done

Note to reviewers: I don't claim to know what I'm doing here. This is probably not the right way of doing it, but it seems to work. Better solutions are very welcome.

This seems like it's OK. The only problem that may crop up is that the DirectoryMemory pre-populates an entry for every block in physical memory (as configured here). So, if the max physical memory is high, you may run out of memory on the host system. Either way, host-system memory will be wasted if there are gaps in the address space with this change.

What does the physical memory layout for ARM look like?

Also, it would be great if you made these changes to all of the protocols, not just MI_example (which shouldn't be used for performance numbers!).

Brad Beckmann July 25, 2016, 12:01 p.m. (July 25, 2016, 12:01 p.m.)

I mostly agree with Jason. It would be great if someone who understood how the Classic memory system handles these sparse physical memory layouts tried to duplicate that logic with the DirectoryMemory. However, I believe that will turn into a big project and require substantial changes to Ruby's component mapping logic (i.e. somehow unify RubySlicc_ComponentMapping and AddrRanges). If and when someone decides to do that, I suggest sending out a detailed proposal to gem5-dev first.

For this patch, just make a similar change to the other Ruby protocol files as Jason suggested. I'll be happy to give it a ship it then.

BTW, at AMD we primarily use SE mode and the process object's simple PA allocation scheme. Thus we have not ran into this issue ourselves. It would be good to have Ruby FS users comment on how they handle sparse physical memory.

Andreas Sandberg Aug. 10, 2016, 9:03 a.m. (Aug. 10, 2016, 9:03 a.m.)

The memory layout depends on the platform, but the new platform (which is the only one to support 4.x kernels) has one contiguous memory staring at 2GiB. There is a boot ROM at a lower address as well, but we don't report it as a memory when using Ruby, so it will be treated as a device.

I suspect the "right" thing to do would be to create one directory per dense memory range. I'm not sure how this interacts with existing NUMA configurations though.

I'm going to discard this review for now since there should be a better solution.

You have a pending review.

Review Board 2.0.15

This change has been discarded.

Screenshots

Files

Status: Discarded