-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3578/#review8529
-----------------------------------------------------------


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!).

- Jason Lowe-Power


On July 22, 2016, 3:08 p.m., Andreas Sandberg wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3578/
> -----------------------------------------------------------
> 
> (Updated July 22, 2016, 3:08 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> 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.sandb...@arm.com>
> Reviewed-by: Nikos Nikoleris <nikos.nikole...@arm.com>
> Reviewed-by: Curtis Dunham <curtis.dun...@arm.com>
> 
> 
> Diffs
> -----
> 
>   configs/ruby/MI_example.py 4aac82f10951 
> 
> Diff: http://reviews.gem5.org/r/3578/diff/
> 
> 
> Testing
> -------
> 
> 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.
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to