> On July 25, 2016, 3:26 p.m., Jason Lowe-Power wrote: > > 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 wrote: > 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.
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. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3578/#review8529 ----------------------------------------------------------- On July 22, 2016, 4: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, 4: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 <[email protected]> > Reviewed-by: Nikos Nikoleris <[email protected]> > Reviewed-by: Curtis Dunham <[email protected]> > > > 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 [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
