[gem5-dev] Removal of RubyMemoryControl

Hi all, With Nilay’s recent improvements to Ruby I would like to understand if there is any point in still having the RubyMemoryControl, or if we should just clean things up a bit and remove it. I would think the best way forward is to clean up the integration of Ruby and classic and ensure

Re: [gem5-dev] Review Request 2463: dev: refactor pci config space for sysfs scanning

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2463/#review5412 --- Ship it! Ship It! - Anthony Gutierrez On Oct. 10, 2014, 10:34 p.m.,

Re: [gem5-dev] Removal of RubyMemoryControl

On Mon, 13 Oct 2014, Andreas Hansson via gem5-dev wrote: Hi all, With Nilay’s recent improvements to Ruby I would like to understand if there is any point in still having the RubyMemoryControl, or if we should just clean things up a bit and remove it. I would think the best way forward is

Re: [gem5-dev] Review Request 2313: kvm, x86: Adding support for SE mode execution

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2313/#review5413 --- src/sim/pseudo_inst.cc http://reviews.gem5.org/r/2313/#comment4900

Re: [gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression --scratch all

I will re-run build/X86/tests/opt/long/fs/10.linux-boot/x86/linux/pc-o3-timing and build/ARM/tests/opt/long/se/40.perlbmk/arm/linux/o3-timing. I updated the stats for these, not sure why zizzer is complaining. I think realview-minor-dual failed due to some issue with its implementation. I

Re: [gem5-dev] Removal of RubyMemoryControl

Hi Nilay, Thanks for the clarification. I believe the RubyMemoryController is completely Pareto dominated by the vanilla DRAMCtrl module, but if there is any specific feature/setting missing I would be keen to know. If possible I would like to make sure we use the same controller as a default

Re: [gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression --scratch all

Hi Nilay, There should be no uninitialized values, at least based on UBSan, valgrind and static analysis. If a regression is indeed failing and the behavior is repeatable, could you try the aforementioned options? Thanks, Andreas On 10/13/14, 9:19 PM, Nilay Vaish via gem5-dev

Re: [gem5-dev] Removal of RubyMemoryControl

Hi guys, Thanks for the clarification. I believe the RubyMemoryController is completely Pareto dominated by the vanilla DRAMCtrl module, but if there is any specific feature/setting missing I would be keen to know. If possible I would like to make sure we use the same controller as a

Re: [gem5-dev] Removal of RubyMemoryControl

Hi Joel, I am happy to spend the 5 minutes creating a GDDR5 configuration. Do you have any specific data sheet you would like to capture? Andreas On 10/13/14, 10:09 PM, Joel Hestness via gem5-dev gem5-dev@gem5.org wrote: Hi guys, Thanks for the clarification. I believe the

Re: [gem5-dev] Removal of RubyMemoryControl

Hi Andreas, Sure thing. We try to closely replicate the parameters used in GPGPU-Sim v3.2.2, which are specified in the Hynix datasheet here: http://www.hynix.com/datasheet/pdf/graphics/H5GQ1H24AFR(Rev1.0).pdf. Here are relevant excerpts from the GPGPU-Sim GTX480 config file (attached): #

Re: [gem5-dev] Removal of RubyMemoryControl

Hi Joel, Thanks. I really do not understand the return queue argument. Why on earth would you need such a large return queue? Surely the agent making the requests (the GPU in this case) should have allocated space for the response, no? Concerning the configuration, what is the assumed clock

Re: [gem5-dev] Removal of RubyMemoryControl

Hi Andreas, Thanks. I really do not understand the return queue argument. Why on earth would you need such a large return queue? Surely the agent making the requests (the GPU in this case) should have allocated space for the response, no? Good question. I believe that buffer is just to get