This is a research simulator. I don't understand why we would remove functionally that allows us to perform high-level boundary experiments. For example, we currently leverage the backing store to determine the performance of a system if a certain subset of acceses take X cycles. Maintaining that feature is important to me.
We have a ton of code that we currently apply on top of the public tree. Maintaining them is a pain whenever there is a substantial system-wide change in the underlying infrastructure. The real problem is the amount of code we have, not your specific change to the clocks. So how big us your bug fix? How bad is the bug? I don't mind you checking in your fix as long as it doesn't touch a lot of Ruby files or change the general APIs for a minor bug. Brad Sent from my Windows Phone ________________________________ From: Nilay<mailto:[email protected]> Sent: 3/8/2013 1:16 To: Beckmann, Brad<mailto:[email protected]> Cc: gem5 Developer List<mailto:[email protected]> Subject: Re: [gem5-dev] changeset in gem5: ruby: remove the functional copy of memory in... On Wed, March 6, 2013 11:05 pm, Beckmann, Brad wrote: > Thanks Nilay for checking this in. I know this is a small patch, but > there was a lot of previous effort on your part to make it happen. Would not have been possible with out your help. > > Going forward, I do think it is important to make the backing store > optional and not remove it completely. I'm fine if we maintain the > default as off, but there are a few times when it is nice to leverage the > backing store for simple boundary experiments. So if we want to enable > the backing store for se mode, is it as simple as setting access_phys_mem > to true and setting the system.physmem.null to true? Can we modify the > se.py/Ruby.py to do this using just one command line parameter? While we can add an option for keeping the functional copy of the memory, I am not keen on it. I am of the view that once we support pio accesses in ruby, we should remove the functional memory completely. > > Nilay, I'm still in the midst of a significant rebase of our tree due to > your clock/time changes. Please hold off on checking any more Ruby > changes until I can get our patches out the door. > I was hoping these patches would not interfere with yours. Are you facing any issues in merging your patches with the clock/time changes? I think I made some errors in those patches. They manifest while trying to create a checkpoint or restore from one. I have some changes that correct should do away with some of the errors. -- Nilay _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
