Re: [gem5-dev] Review Request 2619: cpu: Add L-TAGE branch predictor
On Fri, 6 Mar 2015, Dibakar Gope wrote: On March 4, 2015, 6:54 p.m., Nilay Vaish wrote: OK. I am sorry for not realizing that so many changes would be required to separate out the params just meant for LTAGE. Had I had realized that, I probably would not have asked for it. I think we should break this latest version into two separate patches. The first patch creates these separate sim objects for different predictor types. The second patch adds LTAGE. And I am willing to go with either order between those two patches. That is, if you prefer, you can add LTAGE first and then separate out the predictors. Revised patches, bpred_reorg.patch (separate patch) just re-organizes the branch predictor structure. The ltage patch applies on top of that. ltage.cc and ltage.hh is primarily Andre Seznec's code from branch prediction championship, that code uploaded on the championship website had no copyright on it. Vignyan later edited that code to handle rollback etc while he was at University of Wisconsin-Madison. So I add the copyright as * Copyright (c) 2014 The University of Wisconsin at the top of ltage.cc and ltage.hh and leaving that to the review forum to decide on the copyrights of these two files. Dibakar, can you contact Andre and ask him if he is willing to contribute this code to gem5? Provide him a copy of the license gem5 carries and ask him if he is fine with it or would he prefer some other license? Also ask him under whose copyright would he be willing to publish this code. I think we are not right in discussing this code without Andre's permission. I am deleting this review request. If Andre agrees, repost the patch. I'll leave the reorg patch as is. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2619: cpu: Add L-TAGE branch predictor
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2619/#review5938 --- OK. I am sorry for not realizing that so many changes would be required to separate out the params just meant for LTAGE. Had I had realized that, I probably would not have asked for it. I think we should break this latest version into two separate patches. The first patch creates these separate sim objects for different predictor types. The second patch adds LTAGE. And I am willing to go with either order between those two patches. That is, if you prefer, you can add LTAGE first and then separate out the predictors. - Nilay Vaish On March 4, 2015, 5:52 p.m., Dibakar Gope wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2619/ --- (Updated March 4, 2015, 5:52 p.m.) Review request for Default. Repository: gem5 Description --- It is the L-TAGE predictor from the Branch Prediction Championship, originally coded by Vignyan Reddy, and modified by me. Diffs - configs/common/O3_ARM_v7a.py 8a20e2a1562d src/cpu/inorder/InOrderCPU.py 8a20e2a1562d src/cpu/minor/MinorCPU.py 8a20e2a1562d src/cpu/o3/O3CPU.py 8a20e2a1562d src/cpu/pred/2bit_local.hh 8a20e2a1562d src/cpu/pred/2bit_local.cc 8a20e2a1562d src/cpu/pred/BranchPredictor.py 8a20e2a1562d src/cpu/pred/SConscript 8a20e2a1562d src/cpu/pred/bi_mode.hh 8a20e2a1562d src/cpu/pred/bi_mode.cc 8a20e2a1562d src/cpu/pred/bpred_unit.hh 8a20e2a1562d src/cpu/pred/bpred_unit.cc 8a20e2a1562d src/cpu/pred/bpred_unit_impl.hh 8a20e2a1562d src/cpu/pred/ltage.hh PRE-CREATION src/cpu/pred/ltage.cc PRE-CREATION src/cpu/pred/tournament.hh 8a20e2a1562d src/cpu/pred/tournament.cc 8a20e2a1562d src/cpu/simple/BaseSimpleCPU.py 8a20e2a1562d Diff: http://reviews.gem5.org/r/2619/diff/ Testing --- Thanks, Dibakar Gope ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2680: cpu: o3: record cpi stacks
On Wed, 4 Mar 2015, Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2680/#review5937 --- Should this perhaps be a probe rather? OK, I just read the commit message from the changeset 10023 91faf6649de0. I am going to argue against separating statistics gathering from the so called functional code. One of the ways I use to learn gem5 (or have used) is observing how the statistics are being collected. Moving statistics collection to a separate file, makes that collection code less visible, which is as important as the functional code itself. This approach was being used in ruby originally. And I changed it (changeset 67d9da312ef0) so that a person reading the code knows what statistic is being updated when. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2678: cpu: o3: Remove unused code in iew, add assert instead.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2678/ --- Review request for Default. Repository: gem5 Description --- Changeset 10733:143028d952ec --- cpu: o3: Remove unused code in iew, add assert instead. Diffs - src/cpu/o3/iew_impl.hh 8a20e2a1562d Diff: http://reviews.gem5.org/r/2678/diff/ Testing --- Thanks, Nilay Vaish ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2679: cpu: o3: another assert instead of check
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2679/ --- Review request for Default. Repository: gem5 Description --- Changeset 10734:c922ae8d84f9 --- cpu: o3: another assert instead of check Diffs - src/cpu/o3/commit_impl.hh 8a20e2a1562d Diff: http://reviews.gem5.org/r/2679/diff/ Testing --- Thanks, Nilay Vaish ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2619: cpu: Add L-TAGE branch predictor
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2619/#review5936 --- Several lines seem to have more than 80 characters. src/cpu/pred/BranchPredictor.py http://reviews.gem5.org/r/2619/#comment5193 I suggest that we create a new class for TAGE predictor and move these parameters to that class. - Nilay Vaish On March 3, 2015, 2:53 a.m., Dibakar Gope wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2619/ --- (Updated March 3, 2015, 2:53 a.m.) Review request for Default. Repository: gem5 Description --- It is the L-TAGE predictor from the Branch Prediction Championship, originally coded by Vignyan Reddy, and modified by me. Changeset 10727:73315fc01762 --- [mq]: ltage_updated.patch Diffs - src/cpu/pred/2bit_local.hh 8a20e2a1562d src/cpu/pred/2bit_local.cc 8a20e2a1562d src/cpu/pred/BranchPredictor.py 8a20e2a1562d src/cpu/pred/SConscript 8a20e2a1562d src/cpu/pred/bi_mode.hh 8a20e2a1562d src/cpu/pred/bi_mode.cc 8a20e2a1562d src/cpu/pred/bpred_unit.hh 8a20e2a1562d src/cpu/pred/bpred_unit.cc 8a20e2a1562d src/cpu/pred/bpred_unit_impl.hh 8a20e2a1562d src/cpu/pred/ltage.hh PRE-CREATION src/cpu/pred/ltage.cc PRE-CREATION src/cpu/pred/tournament.hh 8a20e2a1562d src/cpu/pred/tournament.cc 8a20e2a1562d Diff: http://reviews.gem5.org/r/2619/diff/ Testing --- Thanks, Dibakar Gope ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Configuration GUI for gem5
So what does the GUI do? Can you drag and drop different components and then connect as required? Or is it that you can just set values for different variables? Can you provide some screen shots? -- Nilay On Tue, 3 Mar 2015, Marcus Johnson via gem5-dev wrote: Hi, I am a senior at Colorado State University working with two other students under Dr. Sudeep Pasricha on a senior design project. We have created a GUI to aid in configuring gem5 simulations. It currently supports a variety of command line options which are supplied to the se.py and fs.py scripts. We are beginning to implement some exploration functionality, so that on any particular parameter, a user could specify multiple options for which a simulation would run for each. One of the most important advantages this GUI brings is a reduction to the learning curve to using gem5, as well as a huge aid in debugging configuration options. It has many simple error checks to prevent simple mistakes. We would like to contribute this project open-source to the gem5 community, and wanted to see what your thoughts are on integrating it with gem5. We believe there are two different routes we can take: Option 1 would be to push our code to the gem5 repository. If this is an acceptable option, what is a good way to proceed with this? Option 2 would be to have our code run completely independent of gem5 (the user would specify as an option where they have downloaded gem5 code, or we release it as a patch for gem5). If this were the case, is there a good way for us to market this to the gem5 community? What are your thoughts on the above two options? Thanks, Marcus Johnson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2655: config: Fix for 'android' lookup in disk name
I'll push it along with my own patches. -- Nilay On Mon, 2 Mar 2015, Andreas Hansson via gem5-dev wrote: On Feb. 19, 2015, 10:50 p.m., Andreas Hansson wrote: Ship It! Could someone be kind enough to push this? - Andreas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2655/#review5898 --- On Feb. 19, 2015, 10:46 p.m., Rizwana Begum wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2655/ --- (Updated Feb. 19, 2015, 10:46 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10695:74aaa564d5cc --- config: Fix for 'android' lookup in disk name This patch modifies FSConfig.py to look for 'android' only in disk image name. Before this patch, 'android' was searched in full disk path. Diffs - configs/common/FSConfig.py 1a6785e37d81 Diff: http://reviews.gem5.org/r/2655/diff/ Testing --- All quick and long regressions for ARM passed Thanks, Rizwana Begum ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2677: cpu: o3: commit: mark pipeline delay variable as consts
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2677/ --- Review request for Default. Repository: gem5 Description --- Changeset 10713:175c1dba1179 --- cpu: o3: commit: mark pipeline delay variable as consts Diffs - src/cpu/o3/commit.hh 4206946d60fe Diff: http://reviews.gem5.org/r/2677/diff/ Testing --- Thanks, Nilay Vaish ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2675: cpu: o3: combine if with same condition
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2675/ --- Review request for Default. Repository: gem5 Description --- Changeset 10711:fde343df1e97 --- cpu: o3: combine if with same condition Diffs - src/cpu/o3/commit_impl.hh 4206946d60fe Diff: http://reviews.gem5.org/r/2675/diff/ Testing --- Thanks, Nilay Vaish ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2676: cpu: o3: remove unused stat variables.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2676/ --- Review request for Default. Repository: gem5 Description --- Changeset 10712:bb6de70c386f --- cpu: o3: remove unused stat variables. Diffs - src/cpu/o3/commit.hh 4206946d60fe src/cpu/o3/commit_impl.hh 4206946d60fe Diff: http://reviews.gem5.org/r/2676/diff/ Testing --- Thanks, Nilay Vaish ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2674: cpu: o3: remove member variable squashCounter
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2674/ --- Review request for Default. Repository: gem5 Description --- Changeset 10709:e490e8f78f64 --- cpu: o3: remove member variable squashCounter The variable is used in only one place and a whole new function setNextStatus() has been defined just to compute the value of the variable. Instead of calling the function, the value is now computed in the loop that preceded the function call. Diffs - src/cpu/o3/commit.hh 4206946d60fe src/cpu/o3/commit_impl.hh 4206946d60fe Diff: http://reviews.gem5.org/r/2674/diff/ Testing --- Thanks, Nilay Vaish ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2672: x86: implements x87 mult/div instructions
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2672/ --- Review request for Default. Repository: gem5 Description --- Changeset 10707:c4d9cbb17fa9 --- x86: implements x87 mult/div instructions Diffs - src/arch/x86/isa/decoder/x87.isa 4206946d60fe src/arch/x86/isa/insts/x87/arithmetic/division.py 4206946d60fe src/arch/x86/isa/insts/x87/arithmetic/multiplication.py 4206946d60fe Diff: http://reviews.gem5.org/r/2672/diff/ Testing --- Thanks, Nilay Vaish ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2611: cpu: Tidy up the MemTest and make false sharing more obvious
On Sun, 1 Feb 2015, Andreas Hansson wrote: Hi Nilay, I think the “DMA” bit of this tester was broken and rather pointless. In essence the MemTest is only fit for testing false sharing, and that is what it now does. I do not quite understand what a DMA has to do with any of that. Separately we will now have a tester that actually tests actual sharing, and does so using larger chunks of data being touched (in units of whole cache lines). I think this is a much more sensible strategy. What is the value of the “DMA” bit in MemTest and why does it make sense to keep it there? DMA controller is also a party in the memory system. If a ruby protocol provides a DMA controller, then it also needs to be tested for correctness. I think we had it there so that one can choose whether or not to test the DMA controller. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2611: cpu: Tidy up the MemTest and make false sharing more obvious
On Sat, 31 Jan 2015, Andreas Hansson wrote: On Jan. 30, 2015, 9:47 p.m., Nilay Vaish wrote: src/cpu/testers/memtest/MemTest.py, line 55 http://reviews.gem5.org/r/2611/diff/1/?file=43345#file43345line55 Are you sure this should be dropped? I think the coherence protocols that provide a dma controller need this for testing. All regressions work just fine (with stats updates). I am about to post a separate test script that actually shares data (not just false sharing), doing so based on the TrafficGen and MemChecker. Regressions are working probably because we are not testing the DMA controller. I would suggest that we retain the variable. I would change the regressions to test the DMA controller as well. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2611: cpu: Tidy up the MemTest and make false sharing more obvious
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2611/#review5809 --- src/cpu/testers/memtest/MemTest.py http://reviews.gem5.org/r/2611/#comment5129 Are you sure this should be dropped? I think the coherence protocols that provide a dma controller need this for testing. - Nilay Vaish On Jan. 21, 2015, 1:23 p.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2611/ --- (Updated Jan. 21, 2015, 1:23 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10671:94bc71e83168 --- cpu: Tidy up the MemTest and make false sharing more obvious The MemTest class really only tests false sharing, and as such there was a lot of old cruft that could be removed. This patch cleans up the tester, and also makes it more clear what the assumptions are. As part of this simplification the reference functional memory is also removed. The regression configs using MemTest are updated to reflect the changes, and the stats will be bumped in a separate patch. The example config will be updated in a separate patch due to more extensive re-work. In a follow-on patch a new tester will be introduced that uses the MemChecker to implement true sharing. Diffs - configs/example/memtest.py a6fe75e8296b src/cpu/testers/memtest/MemTest.py a6fe75e8296b src/cpu/testers/memtest/memtest.hh a6fe75e8296b src/cpu/testers/memtest/memtest.cc a6fe75e8296b tests/configs/memtest-filter.py a6fe75e8296b tests/configs/memtest-ruby.py a6fe75e8296b tests/configs/memtest.py a6fe75e8296b Diff: http://reviews.gem5.org/r/2611/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Uncachable memory requests in Ruby
Mohammad, how long does it take for your simulation to hit this problem? If it takes about 10 minutes, I suggest that you come over to the CS building so that I can take a look at your setup. -- Nilay On Sat, 24 Jan 2015, Mohammad Alian wrote: After digging into the issue, I found out that ruby actually doesn't cache memory requests within memory mapped devices address range(0xC000-0x) and send them to the pio port. The problem is that when I run gem5 with ruby, some of memory requests which their address is not belong to the reserved memory region for devices reach the iobus and PCI configspace after going through ruby! However no memory request beyond the reserved memory space reaches to the PCI configspace when I use classic memory system. Bellow is the gem5 output and command line. The address of request that reaches PCI configspace is 0x13f21e9c0. I've added 1GB extra memory to ruby memory size based on this post https://www.mail-archive.com/gem5-users@gem5.org/msg11106.html to be able to use ruby for memory size larger than 3GB. command line: ./gem5.opt --debug-flags=PciConfigAll configs/example/fs.py --mem-size=4096MB --num-cpus=1 --cpu-type=timing --ruby -r 1 REAL SIMULATION 2379481334283000: system.pc.pciconfig: read va=0x13f21e9c0 size=16 panic: invalid access size(?) for PCI configspace! @ tick 2379481334283000 [read:build/X86/dev/pciconfigall.cc, line 72] Memory Usage: 5253512 KBytes Program aborted at cycle 2379481334283000 Aborted (core dumped) Any idea about what is going on here and possible fixes? Thank you,Mohammad On Thursday, January 22, 2015 10:28 AM, Mohammad Alian via gem5-dev gem5-dev@gem5.org wrote: Hello, How can I force a request to be uncacheable when using Ruby memory system?req-setFlags(Request::UNCACHEABLE) works for classic memory system but it doesn't have any effect on the request while using Ruby. Thank you,Mohammad ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] X86 regression failures
On Fri, 16 Jan 2015, mike upton via gem5-dev wrote: I was trying to run a regression, I am still learning. This is off of a clean build of the top of tree: hg clone http://repo.gem5.org/gem5 I ran: util/regress -j4 --builds X86 and I get a number of failures. * build/X86/tests/opt/quick/se/00.hello/x86/linux/o3-timing passed * build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-atomic passed * build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing passed * build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing-ruby passed * build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-atomic FAILED! * build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-timing FAILED! The failures are both of the fs tests. Am I doing something wrong? Typically I look at the files simout and simerr in the directory for the test to get an idea about what went wrong. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: stats: changes due to recent changesets.
changeset cd95d4d51659 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=cd95d4d51659 description: stats: changes due to recent changesets. diffstat: tests/long/fs/10.linux-boot/ref/x86/linux/pc-o3-timing/stats.txt | 2463 +++--- tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_Two_Level/stats.txt | 1862 ++--- tests/long/fs/10.linux-boot/ref/x86/linux/pc-switcheroo-full/stats.txt | 3109 - tests/long/se/10.mcf/ref/x86/linux/o3-timing/config.ini | 6 + tests/long/se/10.mcf/ref/x86/linux/simple-atomic/config.ini | 2 + tests/long/se/10.mcf/ref/x86/linux/simple-timing/config.ini | 5 + tests/long/se/20.parser/ref/x86/linux/o3-timing/config.ini | 6 + tests/long/se/20.parser/ref/x86/linux/simple-atomic/config.ini | 2 + tests/long/se/20.parser/ref/x86/linux/simple-timing/config.ini | 5 + tests/long/se/60.bzip2/ref/x86/linux/simple-atomic/config.ini | 2 + tests/long/se/60.bzip2/ref/x86/linux/simple-timing/config.ini | 5 + tests/long/se/70.twolf/ref/x86/linux/o3-timing/config.ini | 6 + tests/long/se/70.twolf/ref/x86/linux/simple-atomic/config.ini | 2 + tests/long/se/70.twolf/ref/x86/linux/simple-timing/config.ini | 5 + tests/quick/fs/10.linux-boot/ref/x86/linux/pc-simple-atomic/stats.txt | 416 +- tests/quick/fs/10.linux-boot/ref/x86/linux/pc-simple-timing/stats.txt | 1941 +++--- tests/quick/se/00.hello/ref/x86/linux/simple-atomic/config.ini | 2 + tests/quick/se/00.hello/ref/x86/linux/simple-timing-ruby/config.ini | 4 +- tests/quick/se/00.hello/ref/x86/linux/simple-timing/config.ini | 5 + 19 files changed, 4933 insertions(+), 4915 deletions(-) diffs (truncated from 11565 to 300 lines): diff -r 24447dc69101 -r cd95d4d51659 tests/long/fs/10.linux-boot/ref/x86/linux/pc-o3-timing/stats.txt --- a/tests/long/fs/10.linux-boot/ref/x86/linux/pc-o3-timing/stats.txt Sat Jan 10 14:30:53 2015 -0600 +++ b/tests/long/fs/10.linux-boot/ref/x86/linux/pc-o3-timing/stats.txt Sat Jan 10 18:06:43 2015 -0600 @@ -1,130 +1,130 @@ -- Begin Simulation Statistics -- -sim_seconds 5.125946 # Number of seconds simulated -sim_ticks5125946039500 # Number of ticks simulated -final_tick 5125946039500 # Number of ticks from beginning of simulation (restored from checkpoints and never reset) +sim_seconds 5.121937 # Number of seconds simulated +sim_ticks5121937205500 # Number of ticks simulated +final_tick 5121937205500 # Number of ticks from beginning of simulation (restored from checkpoints and never reset) sim_freq 1 # Frequency of simulated ticks -host_inst_rate 214937 # Simulator instruction rate (inst/s) -host_op_rate 424847 # Simulator op (including micro ops) rate (op/s) -host_tick_rate 2699457200 # Simulator tick rate (ticks/s) -host_mem_usage 751580 # Number of bytes of host memory used -host_seconds 1898.88 # Real time elapsed on the host -sim_insts 408140259 # Number of instructions simulated -sim_ops 806733017 # Number of ops (including micro ops) simulated +host_inst_rate 133395 # Simulator instruction rate (inst/s) +host_op_rate 263673 # Simulator op (including micro ops) rate (op/s) +host_tick_rate 1674179733 # Simulator tick rate (ticks/s) +host_mem_usage 798472 # Number of bytes of host memory used +host_seconds 3059.37 # Real time elapsed on the host +sim_insts 408103625 # Number of instructions
Re: [gem5-dev] testing/regression update ETA?
On Tue, 6 Jan 2015, mike upton via gem5-dev wrote: Hi, I believe Ali had a proposal for an update to the testing/regression infrastructure. Is there an ETA for that? I would like to automate testing and regressions across a bunch of ISAs. I have available compute resources, but need some handholding on the existing infrastructure. I would like to get to the point that we can test each proposed modification. The current setup can be used through the script: util/regress. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: configs: ruby: removes bug introduced by 05b5...
changeset 64618b7c57b2 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=64618b7c57b2 description: configs: ruby: removes bug introduced by 05b5a6cf3521 diffstat: configs/ruby/Ruby.py | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diffs (24 lines): diff -r 7c649fc84bb9 -r 64618b7c57b2 configs/ruby/Ruby.py --- a/configs/ruby/Ruby.py Sat Dec 27 13:48:40 2014 -0600 +++ b/configs/ruby/Ruby.py Sat Jan 03 17:51:48 2015 -0600 @@ -233,6 +233,11 @@ ruby.num_of_sequencers = len(cpu_sequencers) ruby.random_seed= options.random_seed +# Create a backing copy of physical memory in case required +if options.access_backing_store: +ruby.phys_mem = SimpleMemory(range=AddrRange(options.mem_size), + in_addr_map=False) + def send_evicts(options): # currently, 2 scenarios warrant forwarding evictions to the CPU: # 1. The O3 model must keep the LSQ coherent with the caches @@ -240,8 +245,3 @@ if options.cpu_type == detailed or buildEnv['TARGET_ISA'] == 'x86': return True return False - -# Create a backing copy of physical memory in case required -if options.access_backing_store: -ruby.phys_mem = SimpleMemory(range=AddrRange(options.mem_size), - in_addr_map=False) ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: stats: changes due to recent changesets.
changeset 9ac724889705 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=9ac724889705 description: stats: changes due to recent changesets. diffstat: tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-minor/config.ini | 4 + tests/long/fs/10.linux-boot/ref/alpha/linux/tsunami-minor/stats.txt | 300 +- tests/long/fs/10.linux-boot/ref/arm/linux/realview-minor-dual/stats.txt | 1070 ++- tests/long/fs/10.linux-boot/ref/arm/linux/realview-minor/stats.txt | 347 +- tests/long/fs/10.linux-boot/ref/arm/linux/realview-o3-dual/stats.txt | 4 +- tests/long/fs/10.linux-boot/ref/arm/linux/realview-switcheroo-full/stats.txt | 6 +- tests/long/fs/10.linux-boot/ref/arm/linux/realview64-minor-dual/stats.txt | 1254 ++-- tests/long/fs/10.linux-boot/ref/arm/linux/realview64-minor/stats.txt | 399 +- tests/long/fs/10.linux-boot/ref/x86/linux/pc-o3-timing/stats.txt | 2417 + tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_Two_Level/config.ini |46 +- tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt | 412 +- tests/long/se/10.mcf/ref/arm/linux/minor-timing/config.ini | 7 + tests/long/se/10.mcf/ref/arm/linux/minor-timing/stats.txt | 247 +- tests/long/se/10.mcf/ref/arm/linux/o3-timing/config.ini |31 +- tests/long/se/20.parser/ref/alpha/tru64/minor-timing/stats.txt | 230 +- tests/long/se/20.parser/ref/arm/linux/minor-timing/config.ini | 7 + tests/long/se/20.parser/ref/arm/linux/minor-timing/stats.txt | 247 +- tests/long/se/20.parser/ref/arm/linux/o3-timing/config.ini |31 +- tests/long/se/30.eon/ref/alpha/tru64/minor-timing/stats.txt | 230 +- tests/long/se/30.eon/ref/alpha/tru64/o3-timing/config.ini | 6 + tests/long/se/30.eon/ref/arm/linux/minor-timing/stats.txt | 247 +- tests/long/se/30.eon/ref/arm/linux/o3-timing/config.ini |31 +- tests/long/se/40.perlbmk/ref/alpha/tru64/minor-timing/stats.txt | 230 +- tests/long/se/40.perlbmk/ref/arm/linux/minor-timing/stats.txt | 247 +- tests/long/se/50.vortex/ref/alpha/tru64/minor-timing/stats.txt | 230 +- tests/long/se/50.vortex/ref/alpha/tru64/o3-timing/config.ini | 6 + tests/long/se/50.vortex/ref/arm/linux/minor-timing/stats.txt | 247 +- tests/long/se/50.vortex/ref/arm/linux/o3-timing/config.ini |31 +- tests/long/se/60.bzip2/ref/alpha/tru64/minor-timing/stats.txt | 227 +- tests/long/se/60.bzip2/ref/alpha/tru64/o3-timing/config.ini | 6 + tests/long/se/60.bzip2/ref/arm/linux/minor-timing/stats.txt | 247 +- tests/long/se/60.bzip2/ref/arm/linux/o3-timing/config.ini |31 +- tests/long/se/70.twolf/ref/alpha/tru64/minor-timing/stats.txt | 230 +- tests/long/se/70.twolf/ref/alpha/tru64/o3-timing/config.ini | 6 + tests/long/se/70.twolf/ref/alpha/tru64/simple-timing/config.ini | 5 + tests/long/se/70.twolf/ref/arm/linux/minor-timing/stats.txt | 247 +- tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic-dual/config.ini | 6 + tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-atomic/config.ini | 4 + tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/config.ini |20 +- tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing/config.ini |18 +- tests/quick/fs/10.linux-boot/ref/arm/linux/realview-simple-atomic-dual/config.ini |68 +- tests/quick/fs/10.linux-boot/ref/arm/linux/realview-simple-atomic/config.ini |16 +- tests/quick/fs/10.linux-boot/ref/arm/linux/realview-simple-timing-dual/config.ini |68 +- tests/quick/fs/10.linux-boot/ref/arm/linux/realview-simple-timing/config.ini |16 +- tests/quick/fs/10.linux-boot/ref/arm/linux/realview-switcheroo-atomic/config.ini |16 +- tests/quick/fs/10.linux-boot/ref/arm/linux/realview64-simple-atomic-dual/config.ini |66 +-
Re: [gem5-dev] Review Request 2553: dev: Prevent intel 8254 timer events firing before startup
On Dec. 5, 2014, 11:45 a.m., Andreas Hansson wrote: Look good to me. Do the regressions still pass? Cagdas Dirik wrote: I ran the same tests as I mentioned in r/2545. Please let me know if I need to test more. Cagdas Dirik wrote: This very likely needs updates similar to r/2545 to carry the changes for alpha and mips. I am working on an update. Cagdas Dirik wrote: I have changes ready for alpha and mips, but they are on top of r/2545, and I don't know how to reflect that diff dependency here. So may be better to have r/2545 to be finished and submitted first. And then I will update this one. Also I could not convince myself yet if src/dev/x86/speaker.* needs editing as well. It uses I8254 but it does not serialize/unserialize it, so I am not sure if it needs a timer-startup() call. This should also give me time to take a better look. What's the status of this patch? - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2553/#review5642 --- On Dec. 4, 2014, 7:14 p.m., Cagdas Dirik wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2553/ --- (Updated Dec. 4, 2014, 7:14 p.m.) Review request for Default, Andrew Bardsley, Andreas Hansson, and Ali Saidi. Repository: gem5 Description --- This change includes edits to Intel8254Timer to prevent counter events firing before startup to comply with SimObject initialization call sequence. Diffs - src/dev/intel_8254_timer.hh fea29fc045ee src/dev/intel_8254_timer.cc fea29fc045ee src/dev/x86/i8254.hh fea29fc045ee src/dev/x86/i8254.cc fea29fc045ee Diff: http://reviews.gem5.org/r/2553/diff/ Testing --- Thanks, Cagdas Dirik ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2548: arm: Add unlinkat syscall implementation
Would do it sometime this week. I also need to take a look if there are requests from other users. -- Nilay On Mon, 29 Dec 2014, Andreas Hansson via gem5-dev wrote: On Dec. 5, 2014, 5:45 p.m., Steve Reinhardt wrote: Ship It! mike upton wrote: Is there something blocking this change? Nilay, would you by any chance be able to push this? - Andreas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2548/#review5646 --- On Dec. 5, 2014, 1:14 a.m., mike upton wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2548/ --- (Updated Dec. 5, 2014, 1:14 a.m.) Review request for Default. Repository: gem5 Description --- arm: Add unlinkat syscall implementation added ARM aarch64 unlinkat syscall support, modeled on other xxxat syscalls. This gets all of the cpu2006 int workloads passing in SE mode on aarch64. hmmer, omnetpp Diffs - src/arch/arm/linux/process.cc ad9146bb5598 src/sim/syscall_emul.hh ad9146bb5598 src/sim/syscall_emul.cc ad9146bb5598 Diff: http://reviews.gem5.org/r/2548/diff/ Testing --- build/ARM/tests/opt/quick/se SPEC CPU2006 integer apps, test and train input sizes Thanks, mike upton ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: Added tag stable_2014_12_14 for changeset bdb...
changeset a0cb57e1c072 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=a0cb57e1c072 description: Added tag stable_2014_12_14 for changeset bdb307e8be54 diffstat: .hgtags | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diffs (8 lines): diff -r 8fc6e7a835d1 -r a0cb57e1c072 .hgtags --- a/.hgtags Tue Dec 09 21:53:44 2014 -0800 +++ b/.hgtags Sun Dec 14 16:21:04 2014 -0600 @@ -25,3 +25,4 @@ 6a043adb1e8d67fbb03ac5cee58dd26f75663714 stable_2013_10_14 459491344fcf7f9e29250e71f33a7c7150f54d64 stable_2014_02_15 cb2e6950956d475da97b04c41f19769ce2e8541a stable_2014_08_26 +bdb307e8be54a5808a9af2537e9261d88de6ed1b stable_2014_12_14 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Update gem5-stable
I have updated gem5-stable to the version mentioned below. -- Nilay On Thu, 4 Dec 2014, Nilay Vaish wrote: Hello everyone Nearly four months have passed since we updated gem5-stable. I am planning to move it forward on 15th December. The changeset I have on my mind is: changeset: 10436:bdb307e8be54 user:Andrew Lukefahr lukef...@umich.edu date:Sat Oct 11 15:02:22 2014 -0500 summary: sim: draining bug for fast-forwaring multiple cores This would mean adding about 235 patches to gem5-stable. Note that we no longer maintain the same changeset order between gem5 and gem5-stable. So I am willing to cherry pick bug fixes that were pushed after the changeset suggested. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2549: ruby: ruby port: do not check for blocked ports
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2549/ --- (Updated Dec. 9, 2014, 3:15 p.m.) Review request for Default. Summary (updated) - ruby: ruby port: do not check for blocked ports Repository: gem5 Description (updated) --- Changeset 10602:d3bb9d95bf76 --- ruby: ruby port: do not check for blocked ports RubyPort used to maintain a list of blocked ports which are sent retries when the port becomes unblocked. This is unnecessary since RubyPort's port definitions inherit from QueuedPort. Diffs (updated) - src/mem/ruby/system/RubyPort.hh 6efb37480d87 src/mem/ruby/system/RubyPort.cc 6efb37480d87 Diff: http://reviews.gem5.org/r/2549/diff/ Testing --- Thanks, Nilay Vaish ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2549: ruby: ruby port: do not check for blocked ports
On Tue, 9 Dec 2014, Brad Beckmann wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2549/#review5657 --- src/mem/ruby/system/RubyPort.cc http://reviews.gem5.org/r/2549/#comment5048 Why are you removing these lines? Is the tester now aware when the port is blocked and does it handle retries correctly? I would prefer if it did not. We want the tester to be as aggressive as possible. I am aware that the tester needs to change. Brad, is there any problem if the tester just tries to send packets even when the port is blocked? At most it would fail. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
I also faced problem in getting KVM CPU to run in FS mode. I figured that the following changeset causes problems: author Alexandru Dutu alexandru.d...@amd.com Sun Nov 23 18:01:08 2014 -0800 (2 weeks ago) changeset 10554 fe2e2f06a7c8 I saw the hardware reason 0x8021, but did not try to figure what was going on wrong. -- Nilay On Mon, 8 Dec 2014, Gabe Black via gem5-dev wrote: I'm pretty sure entering 64 bit mode is the same between AMD and Intel CPUs. I vaguely remember there being some subtle page table difference though, and gem5 is building the page tables in SE mode instead of the kernel. Gabe On Mon, Dec 8, 2014 at 7:44 PM, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org wrote: Hi Mike, trace-cmd is a very handy tool to get an overview of what the kvm kernel module is doing before going into gdb. In extreme cases ftrace can be useful as well. What is the error that you are seeing? Is it still failing to enter virtualized mode? If that is the case and the hardware reason is 0x8021, that seems to be an unrecoverable exception (drivers/hv/hyperv_vmbus.h in linux kernel source code). When running in SE mode, we are trying to bring the machine state to full 64bit mode without going through legacy modes. It might be that Intel machines have a different way of going to 64bit mode than AMD machines (different CR4, different way of enabling 64bit mode page tables etc.). I remember dealing with these issue for AMD platforms by going through System Programming manual and making sure gem5 gets all the bits right as there is not much the KVM kernel model will tell about the cause of failure. Best regards, Alex From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Gabe Black via gem5-dev [gem5-dev@gem5.org] Sent: Monday, December 08, 2014 7:08 PM To: gem5 Developer List Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) I'm not an expert either, but I did have problems running KVM in SE mode on an Intel CPU. I didn't look into it that much, but I think things failed in the kernel somewhere. What might be happening is that the different vendors hardware virtualization mechanisms are more or less picky about various things. Something might be set up incorrectly, and one implementation gets more upset about it than the other. I believe there are tools which will help you determine whether your VM state is legal. Perhaps Andreas can tell you more about those? Gabe On Mon, Dec 8, 2014 at 4:29 PM, mike upton via gem5-dev gem5-dev@gem5.org wrote: I have verified that x86 kvm works fine on AMD platforms, but fails on Intel platforms. Any hints about how to narrow down the cause (other than diving into gdb, which I will do). I am not an expert in KVM or how gem5 hooks up to libkvm. ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: config: ruby: mi protocol: correct master sla...
changeset fea29fc045ee in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=fea29fc045ee description: config: ruby: mi protocol: correct master slave setting for dma In the MI protocol, the master slave connection between the dma controller and network was being set incorrectly. This patch corrects it. diffstat: configs/ruby/MI_example.py | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diffs (14 lines): diff -r ad9146bb5598 -r fea29fc045ee configs/ruby/MI_example.py --- a/configs/ruby/MI_example.pyTue Dec 02 22:01:51 2014 -0800 +++ b/configs/ruby/MI_example.pyThu Dec 04 08:59:44 2014 -0600 @@ -154,8 +154,8 @@ dma_cntrl_nodes.append(dma_cntrl) # Connect the directory controllers and the network -dma_cntrl.requestToDir = ruby_system.network.master -dma_cntrl.responseFromDir = ruby_system.network.slave +dma_cntrl.requestToDir = ruby_system.network.slave +dma_cntrl.responseFromDir = ruby_system.network.master all_cntrls = l1_cntrl_nodes + dir_cntrl_nodes + dma_cntrl_nodes ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2524: config: Add two options for setting the kernel command line.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2524/#review5617 --- Ship it! Ship It! - Nilay Vaish On Nov. 23, 2014, 7:26 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2524/ --- (Updated Nov. 23, 2014, 7:26 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10561:b2a85a0c0571 --- config: Add two options for setting the kernel command line. Both options accept template which will, through python string formatting, have mem, disk, and script values substituted in from the mdesc. Additional values can be used on a case by case basis by passing them as keyword arguments to the fillInCmdLine function. That makes it possible to have specialized parameters for a particular ISA, for instance. The first option lets you specify the template directly, and the other lets you specify a file which has the template in it. Diffs - configs/common/FSConfig.py 6317351a288c0349c5855c7431bc1eeade61605c configs/common/Options.py 6317351a288c0349c5855c7431bc1eeade61605c configs/example/fs.py 6317351a288c0349c5855c7431bc1eeade61605c Diff: http://reviews.gem5.org/r/2524/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2548: arm: Add unlinkat syscall implementation
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2548/#review5618 --- src/sim/syscall_emul.hh http://reviews.gem5.org/r/2548/#comment5021 How will the compiler choose between the two versions of unlinkFunc? I think we should either drop the default argument or drop the second version. src/sim/syscall_emul.hh http://reviews.gem5.org/r/2548/#comment5022 The parameters on the second line need to be aligned with ones in the first line. src/sim/syscall_emul.cc http://reviews.gem5.org/r/2548/#comment5023 Parameter needs to be aligned, - Nilay Vaish On Dec. 3, 2014, 7:10 p.m., mike upton wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2548/ --- (Updated Dec. 3, 2014, 7:10 p.m.) Review request for Default. Repository: gem5 Description --- arm: Add unlinkat syscall implementation added ARM aarch64 unlinkat syscall support, modeled on other xxxat syscalls. This gets all of the cpu2006 int workloads passing in SE mode on aarch64. hmmer, omnetpp Diffs - src/arch/arm/linux/process.cc ad9146bb5598 src/sim/syscall_emul.hh ad9146bb5598 src/sim/syscall_emul.cc ad9146bb5598 Diff: http://reviews.gem5.org/r/2548/diff/ Testing --- build/ARM/tests/opt/quick/se SPEC CPU2006 integer apps, test and train input sizes Thanks, mike upton ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2506: x86: Rework opcode parsing to support 3 byte opcodes properly.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2506/#review5619 --- Ship it! Ship It! - Nilay Vaish On Nov. 17, 2014, 6:57 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2506/ --- (Updated Nov. 17, 2014, 6:57 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10540:966f0b63a495 --- x86: Rework opcode parsing to support 3 byte opcodes properly. Instead of counting the number of opcode bytes in an instruction and recording each byte before the actual opcode, we can represent the path we took to get to the actual opcode byte by using a type code. That has a couple of advantages. First, we can disambiguate the properties of opcodes of the same length which have different properties. Second, it reduces the amount of data stored in an ExtMachInst, making them slightly easier/faster to create and process. This also adds some flexibility as far as how different types of opcodes are handled, which might come in handy if we decide to support VEX or XOP instructions. This change also adds tables to support properly decoding 3 byte opcodes. Before we would fall off the end of some arrays, on top of the ambiguity described above. This change doesn't measureably affect performance on the twolf benchmark. Diffs - src/arch/x86/decoder.hh 1a9e235cab09e37837819876d28fbd2914a47291 src/arch/x86/decoder.cc 1a9e235cab09e37837819876d28fbd2914a47291 src/arch/x86/decoder_tables.cc 1a9e235cab09e37837819876d28fbd2914a47291 src/arch/x86/isa/bitfields.isa 1a9e235cab09e37837819876d28fbd2914a47291 src/arch/x86/isa/decoder/decoder.isa 1a9e235cab09e37837819876d28fbd2914a47291 src/arch/x86/isa/decoder/locked_opcodes.isa 1a9e235cab09e37837819876d28fbd2914a47291 src/arch/x86/isa/decoder/one_byte_opcodes.isa 1a9e235cab09e37837819876d28fbd2914a47291 src/arch/x86/isa/decoder/three_byte_opcodes.isa 1a9e235cab09e37837819876d28fbd2914a47291 src/arch/x86/isa/decoder/three_byte_opcodes.isa 1a9e235cab09e37837819876d28fbd2914a47291 src/arch/x86/isa/decoder/two_byte_opcodes.isa 1a9e235cab09e37837819876d28fbd2914a47291 src/arch/x86/isa_traits.hh 1a9e235cab09e37837819876d28fbd2914a47291 src/arch/x86/types.hh 1a9e235cab09e37837819876d28fbd2914a47291 src/arch/x86/types.cc 1a9e235cab09e37837819876d28fbd2914a47291 Diff: http://reviews.gem5.org/r/2506/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2505: arch: Allow named constants as decode case values.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2505/#review5620 --- Ship it! Ship It! - Nilay Vaish On Dec. 3, 2014, 11:56 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2505/ --- (Updated Dec. 3, 2014, 11:56 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10590:1c185336bb80 --- arch: Allow named constants as decode case values. The values in a bitfield or in an ExtMachInst structure member may not be a literal value, it might select from an arbitrary collection of options. Instead of using the raw value of those constants in the decoder, it's easier to tell what's going on if they can be referred to as a symbolic constant/enum. To support that, the ISA description language is extended slightly so that in addition to integer literals, the case value for decode blobs can also be a string literal. It's up to the ISA author to ensure that the string evaluates to a legal constant value when interpretted as C++. Diffs - src/arch/isa_parser.py 5962812f80fef83240fcb023806e523aa257c2fd Diff: http://reviews.gem5.org/r/2505/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2276: ruby: don't make O3 CPU squash on loads that hit outstanding requests
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2276/#review5621 --- Steve, is it all right to buffer requests in the Sequencer? I am not even in favor of having a sequencer and buffering requests makes it worse. src/mem/ruby/system/Sequencer.cc http://reviews.gem5.org/r/2276/#comment5024 initialize to false? - Nilay Vaish On June 21, 2014, 5 p.m., Steve Reinhardt wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2276/ --- (Updated June 21, 2014, 5 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10240:b01d667ec431 --- ruby: don't make O3 CPU squash on loads that hit outstanding requests Mismatch between O3 and Ruby in handling aliased requests: Ruby returns false when it sees aliased request or memory blocked. O3 squash and refetch when it sees false signal from Ruby. Fix: Merging readRequestTable and writeRequestTable in a single table that maps requesting address and all requests that are aliased with the address. This work was done while Binh was an intern at AMD Research. Diffs - src/mem/packet.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 src/mem/protocol/RubySlicc_Exports.sm b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 src/mem/ruby/system/DMASequencer.hh b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 src/mem/ruby/system/DMASequencer.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 src/mem/ruby/system/RubyPort.hh b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 src/mem/ruby/system/RubyPort.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 src/mem/ruby/system/RubyPortProxy.hh b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 src/mem/ruby/system/RubyPortProxy.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 src/mem/ruby/system/Sequencer.hh b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 src/mem/ruby/system/Sequencer.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 Diff: http://reviews.gem5.org/r/2276/diff/ Testing --- Thanks, Steve Reinhardt ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2549: ruby: do not try to issue request if port blocked
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2549/ --- Review request for Default. Repository: gem5 Description --- Changeset 10592:f019204420e8 --- ruby: do not try to issue request if port blocked Changeset bc3126a05a7f added an assert that port should not be blocked while issuing a request. On receiving a request We actually do not check at all whether the port is available. This patch adds a check. In case blocked, we return false from the recvTiming() function. Diffs - src/mem/ruby/system/RubyPort.hh fea29fc045ee src/mem/ruby/system/RubyPort.cc fea29fc045ee Diff: http://reviews.gem5.org/r/2549/diff/ Testing --- Thanks, Nilay Vaish ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] KVM CPU when using multiple cores
I have been trying to run ht kvm cpu when using multiple cores. With single threaded simulation, the simulation stops making progress if the simulated system has more than 4 cores. With multi-threaded simulation, I do not see any progress even when two cores are being simulated. For the multi-threaded simulation, I made the following changes as suggested in the comment for the changeset: 10157:5c2ecad1a3c9. So, how many cores have others tested kvm cpu with? Is there something that I might not be doing right? diff --git a/configs/example/fs.py b/configs/example/fs.py --- a/configs/example/fs.py +++ b/configs/example/fs.py @@ -121,9 +121,11 @@ test_sys.have_virtualization = True test_sys.init_param = options.init_param +test_sys.eventq_index = np # For now, assign all the CPUs to the same clock domain -test_sys.cpu = [TestCPUClass(clk_domain=test_sys.cpu_clk_domain, cpu_id=i) +test_sys.cpu = [TestCPUClass(clk_domain=test_sys.cpu_clk_domain, cpu_id=i, + eventq_index = i) for i in xrange(np)] if is_kvm_cpu(TestCPUClass) or is_kvm_cpu(FutureClass): @@ -153,6 +155,7 @@ cpu.clk_domain = test_sys.cpu_clk_domain cpu.createThreads() cpu.createInterruptController() +cpu.interrupts.eventq_index = np cpu.icache_port = test_sys.ruby._cpu_ports[i].slave cpu.dcache_port = test_sys.ruby._cpu_ports[i].slave @@ -310,5 +313,6 @@ if options.frame_capture: VncServer.frame_capture = True +root.sim_quantum = 100 Simulation.setWorkCountOptions(test_sys, options) Simulation.run(options, root, test_sys, FutureClass) Thanks Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Protocol Specific Profiling
I am beginning work on this now. On Wed, 3 Dec 2014, Beckmann, Brad wrote: Thanks Nilay for the response. I like the idea of statically defining MachineType and all the associated helper functions. Let's plan on doing that. Brad -Original Message- From: Nilay Vaish [mailto:ni...@cs.wisc.edu] Sent: Wednesday, December 03, 2014 11:26 AM To: Beckmann, Brad Cc: gem5 Developer List (gem5-dev@gem5.org) Subject: RE: Protocol Specific Profiling On Wed, 3 Dec 2014, Beckmann, Brad wrote: I have more questions/issues on this topic of protocol specific profiling. I do not believe this issues should be fixed by having SLICC understand more STL types. I should have pointed out before that many times it is not one specific protocol that needs special profiling, but rather a set of protocols that need special profiling. In the past, this has been handled by adding special profiling to either the profiler or sequencer, often by using the GenericMachineType. Unfortunately, you've removed GenericMachineType so if one where to compile a protocol that did not create those specific machine types, any special profiling functions that relied on them will fail to build. Why did you remove that enum definition from RubySlicc_Types.sm? Is there any reason we cannot add it back? I am ok with adding GenericMachineType back. In addition, I would prefer that we stop defining MachineType dynamically and instead make each MachineType used in a .sm file be one of those generic types. I think this will also allow us to compile all the protocols simultaneously. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Update gem5-stable
Hello everyone Nearly four months have passed since we updated gem5-stable. I am planning to move it forward on 15th December. The changeset I have on my mind is: changeset: 10436:bdb307e8be54 user:Andrew Lukefahr lukef...@umich.edu date:Sat Oct 11 15:02:22 2014 -0500 summary: sim: draining bug for fast-forwaring multiple cores This would mean adding about 235 patches to gem5-stable. Note that we no longer maintain the same changeset order between gem5 and gem5-stable. So I am willing to cherry pick bug fixes that were pushed after the changeset suggested. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2550: ruby: slicc: remove support for single machine, multiple types
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2550/ --- Review request for Default. Repository: gem5 Description --- Changeset 10593:28919388 --- ruby: slicc: remove support for single machine, multiple types It was possible to specify multiple machine types with a single state machine. This seems unnecessary and is being removed. Diffs - src/mem/slicc/ast/MachineAST.py fea29fc045ee src/mem/slicc/parser.py fea29fc045ee Diff: http://reviews.gem5.org/r/2550/diff/ Testing --- Thanks, Nilay Vaish ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2551: ruby: slicc: have a static MachineType
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2551/ --- Review request for Default. Repository: gem5 Description --- Changeset 10594:b25131489b95 --- ruby: slicc: have a static MachineType This patch moves from a dynamically defined MachineType to a statically defined one. The need for this patch was felt since a dynamically defined type prevents us from having types for which no machine definition may exist. The following changes have been made: i. each machine definition now uses a type from the MachineType enumeration instead of any random identifier. This required changing the grammar and the *.sm files. ii. MachineType enumeration defined statically in RubySlicc_Exports.sm. Diffs - src/mem/protocol/MESI_Two_Level-L1cache.sm fea29fc045ee src/mem/protocol/MESI_Two_Level-L2cache.sm fea29fc045ee src/mem/protocol/MESI_Two_Level-dir.sm fea29fc045ee src/mem/protocol/MESI_Two_Level-dma.sm fea29fc045ee src/mem/protocol/RubySlicc_Exports.sm fea29fc045ee src/mem/slicc/ast/DeclListAST.py fea29fc045ee src/mem/slicc/ast/MachineAST.py fea29fc045ee src/mem/slicc/parser.py fea29fc045ee src/mem/slicc/symbols/SymbolTable.py fea29fc045ee src/mem/slicc/symbols/Type.py fea29fc045ee Diff: http://reviews.gem5.org/r/2551/diff/ Testing --- Thanks, Nilay Vaish ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] how to post diff files on review board
I think the problem you are experiencing happens when reviewboard is unable to figure out the version of the repo on which to apply your patch. Initially I also used to use the web interface posting reviews. But now I use the reviewboard extension of mercurial. I find it less error prone. For a new review request, I use: hg postreview -o tip. For updating a request, I use: hg postreview -p -e review id -u. -- Nilay On Thu, 4 Dec 2014, Cagdas Dirik \(cdirik\) via gem5-dev wrote: I am having a problem uploading my diff files for a review request. I generated diff file using hg export but when I upload them to review board I keep getting hunk failed error messages, but no reason why. Diff file looks normal. Any ideas on what may be wrong? Or am I using wrong process to update a review request? Case in question is r/2545: http://reviews.gem5.org/r/2545/ Thanks in advance. Cagdas ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] KVM CPU when using multiple cores
The simulator. As in different cores of the simulated system are simulated on different threads of the host system. -- Nilay On Thu, 4 Dec 2014, Gabe Black via gem5-dev wrote: This is somewhat tangential, but are you saying the simulator is multithreaded now? Or just your simulation? Gabe On Thu, Dec 4, 2014 at 10:03 AM, Andreas Sandberg via gem5-dev gem5-dev@gem5.org wrote: On 04/12/14 16:10, Nilay Vaish via gem5-dev wrote: I have been trying to run ht kvm cpu when using multiple cores. With single threaded simulation, the simulation stops making progress if the simulated system has more than 4 cores. With multi-threaded simulation, I do not see any progress even when two cores are being simulated. For the multi-threaded simulation, I made the following changes as suggested in the comment for the changeset: 10157:5c2ecad1a3c9. So, how many cores have others tested kvm cpu with? Is there something that I might not be doing right? I reported scalability numbers up to 8 cores for one of the Splash 2 benchmarks in my thesis, so 8 cores definitely work. IIRC, I tested it on 32 cores as well, but I didn't report those numbers. There are three issues you might be running into: * There might be devices (CPU child objects) that don't live in the right thread. * The quantum might be too large (I never managed to get anything more than 1ms to work). * Newly introduced bugs. The code fragment I used in my old scripts was something like this: if not no_kvm and cpus 1: test_sys.eventq_index = 0 for idx, cpu in enumerate(test_sys.cpu_boot): for obj in cpu.descendants(): obj.eventq_index = test_sys.eventq_index cpu.eventq_index = idx + 1 The fragment above ensures that any descendants of the CPU are assigned to the device thread and only the CPU lives in a separate thread. //Andreas -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Protocol Specific Profiling
On Wed, 3 Dec 2014, Beckmann, Brad wrote: I have more questions/issues on this topic of protocol specific profiling. I do not believe this issues should be fixed by having SLICC understand more STL types. I should have pointed out before that many times it is not one specific protocol that needs special profiling, but rather a set of protocols that need special profiling. In the past, this has been handled by adding special profiling to either the profiler or sequencer, often by using the GenericMachineType. Unfortunately, you've removed GenericMachineType so if one where to compile a protocol that did not create those specific machine types, any special profiling functions that relied on them will fail to build. Why did you remove that enum definition from RubySlicc_Types.sm? Is there any reason we cannot add it back? I am ok with adding GenericMachineType back. In addition, I would prefer that we stop defining MachineType dynamically and instead make each MachineType used in a .sm file be one of those generic types. I think this will also allow us to compile all the protocols simultaneously. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2528: config: make M5_PATH a real search path
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2528/#review5603 --- Ship it! Ship It! - Nilay Vaish On Nov. 24, 2014, 2:48 a.m., Steve Reinhardt wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2528/ --- (Updated Nov. 24, 2014, 2:48 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10559:ad009eb6579b --- config: make M5_PATH a real search path Although you can put a list of colon-separated directory names in M5_PATH, the current code just takes the first one that exists and assumes all files must live there. This change makes the code search the specified list of directories for each individual binary or disk image that's requested. The main motivation is that the x86/Alpha binaries and the ARM binaries are in separate downloads, and thus naturally end up in separate directories. With this change, you can have M5_PATH point to those two directories, then run any FS regression test without changing M5_PATH. Currently, you either have to merge the two download directories or change M5_PATH (or do something else I haven't figured out). Diffs - configs/common/SysPaths.py 426665ec11a925e983edbd94d4941615c5dd25fe Diff: http://reviews.gem5.org/r/2528/diff/ Testing --- Thanks, Steve Reinhardt ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2538: misc: Make the GDB register cache accessible in various sized chunks.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2538/#review5604 --- Ship it! Seems fine other than the one comment I have made below. src/base/remote_gdb.hh http://reviews.gem5.org/r/2538/#comment5014 Should this not be divCeil() * sizeof(uint64_t)? - Nilay Vaish On Nov. 25, 2014, 11:47 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2538/ --- (Updated Nov. 25, 2014, 11:47 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10566:b350c8558d2f --- misc: Make the GDB register cache accessible in various sized chunks. Not all ISAs have 64 bit sized registers, so it's not always very convenient to access the GDB register cache in 64 bit sized chunks. This change makes it accessible in 8, 16, 32, or 64 bit chunks. The MIPS and ARM implementations were working around that limitation by bundling and unbundling 32 bit values into 64 bit values. That code has been removed. Diffs - src/arch/alpha/remote_gdb.cc f9fb64a72259a2514080151b5250a04c575d443a src/arch/arm/remote_gdb.hh f9fb64a72259a2514080151b5250a04c575d443a src/arch/arm/remote_gdb.cc f9fb64a72259a2514080151b5250a04c575d443a src/arch/mips/remote_gdb.hh f9fb64a72259a2514080151b5250a04c575d443a src/arch/mips/remote_gdb.cc f9fb64a72259a2514080151b5250a04c575d443a src/arch/sparc/remote_gdb.cc f9fb64a72259a2514080151b5250a04c575d443a src/base/remote_gdb.hh f9fb64a72259a2514080151b5250a04c575d443a Diff: http://reviews.gem5.org/r/2538/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2541: sim: Make it possible to override the breakpoint length check.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2541/#review5605 --- Ship it! Ship It! - Nilay Vaish On Nov. 25, 2014, 11:47 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2541/ --- (Updated Nov. 25, 2014, 11:47 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10569:87cda70be35d --- sim: Make it possible to override the breakpoint length check. The check which makes sure the length of the breakpoint being written is the same as a MachInst is only correct on fixed instruction width ISAs. Instead of incorrectly applying that check to all ISAs, this change makes that the default check and lets ISA specific GDB classes override it. Diffs - src/base/remote_gdb.hh f9fb64a72259a2514080151b5250a04c575d443a src/base/remote_gdb.cc f9fb64a72259a2514080151b5250a04c575d443a Diff: http://reviews.gem5.org/r/2541/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] changeset in gem5: ruby: slicc: change the way configurable memb...
On Tue, 2 Dec 2014, Beckmann, Brad wrote: Hi Nilay, Could you explain the motivation behind this change? What was wrong with the previous notation that data member declarations are separated by commas rather than semi-colons? I think in most places in SLICC we use comma to separate the attributes of a variable. So, having a different meaning for comma when used while declaring parameters does not seem right to me. Second, message buffers typically have several attributes with them. If we were to retain the comma as separator, then it would not be possible to specify message buffers as parameters. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2522: ide: Accept the IDLE (0xe3) ATA command.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2522/#review5590 --- Ship it! dev: ide: in the summary line. - Nilay Vaish On Nov. 22, 2014, 2:39 p.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2522/ --- (Updated Nov. 22, 2014, 2:39 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10559:49c207fbc3fc --- ide: Accept the IDLE (0xe3) ATA command. This command is supposed to set up a timer which will put the drive into a standby mode if it isn't sent a command within a given time out. Since most of the timeouts are generally significantly longer than a simulation would run anyway, and we don't have an implementation for standby mode to begin with, we can accept the command, do nothing, and report success. Diffs - src/dev/ide_disk.cc 6317351a288c0349c5855c7431bc1eeade61605c Diff: http://reviews.gem5.org/r/2522/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Issue with O3 and interrupts
function of the X86 Fault implementation arch/x86/fault.cc. This function saves the PC and the interrupt vector in the micro arch registers and calls the code at the Microcode rom (isa/insts/romutil.py) longModeInterrupt by setting the uPC. This routine saves the pc in the stack, and calculates the address to the OS interrupt service routine using the interrupt vector. Then the simulator will forget about this fault. If we have a second interrupt when the first interrupt sets this registers but hadn't completed the fetch of the first instruction of the longModeInterrupt routine, the O3 CPU will detect an empty rob and will allow this interrupt to proceed. It will overwrite the registers holding the pc and the interrupt vector, that had not the chance of being saved. Therefore the first interruption data will be lost, and when the longModeInterrupt code first instruction arrives, it sees the status (vector) of the second interruption. I did a hack to fix this situation where I completely disable the interrupts during the time window between the set of this registers and the Microcode rom execution. I added a new register that when set to 0x1, every single interruption is ignored at the x86/interrupt.cc checkInterrupts function. This had to be done because setting the IF at the flags registers do not disable all the interruptions. Then I added a new microop at the x86 arch. that sets this register to 0. I modified the routine that does all the above to call this new instruction at the end. This way I made it work, its a bit hacky solution so there might be some other elegant ways to solve this issue. Hope this can be helpful. Best regards. De: gem5-dev [gem5-dev-boun...@gem5.org] en nombre de Nilay Vaish via gem5-dev [gem5-dev@gem5.org] Enviado: viernes, 28 de noviembre de 2014 16:03 Para: Castillo Villar, Emilio via gem5-dev Asunto: Re: [gem5-dev] Issue with O3 and interrupts Ok, I have not seen this problem, but I got the description below. So what's your suggestion on fixing the problem? Should we add a stack of pending interrupts instead of maintaining one single variable? -- Nilay On Wed, 26 Nov 2014, Castillo Villar, Emilio via gem5-dev wrote: Good evening, I am experiencing a weird issue with the O3CPU, X86 and the interrupt handling. I am running in FS mode and one simulation just experienced a weird hang. The simulated machine is doing an spinlock over a value that an interrupt handler writes. After some debug I found that when the APIC sends two interruptions to the cpu in a very short time window, the first interruption is completely ignored. It can not even complete a commit of the first instruction in the service routine before all its values get replaced by the next interrupt. After this interrupt completes, the execution goes back to the application code and do not execute the code for the first interrupt. The problem is that the Lapic has the vector of the first interruption in the ISR register as it gets restored after the second interruption completes. Therefore, it thinks that the cpu is currently processing that interruption, though the cpu went back to execute application code and will never clear this ISR register. The Lapic uses this ISR value to filter incoming interruptions and in several cases, it does not forward those to the cpu, leading to unattended interruptions and hangs. I have seen this behavior in the kernels' native_flush_tlb_others function when a page fault happens. The core in charge of executing it, sends an interrupt to all the other cores in the system and it does a loop checking that every cores receive the interruption. When each core receives the interruption, they just execute the associated handler and perform a write to a variable, notifying the sender that the interruption was processed and the tlb was flushed. The problem is that one of the cores is ignoring this interruption, which has a vector value of 0xf0. I found that this core lapic has a value of 0xf1 in the ISR, filtering every lower vector. s This 0xf1 vector value was set by an interruption that never got to execute because of the problem explained before, hence the interruption carrying the 0xf0 vector value will never be executed and the native_flush_tlb_others function will not complete. I just took a trace of the moment when the 0xf1 interruption gets dropped. The flags used where Exec, Commit, Faults: system.cpu00.interrupts: Interrupt 0xf1 sent to core. 7175754213000: External Interrupt: RIP 0x8027a0a0: vector 0xf1: #INTR 7175754213000: system.cpu00.interrupts: NEW IRR 0 NEW ISR f1. Now the interrupt 0xf3 gets to execute and drops all the first interruption. 7175754217000: system.cpu00.interrupts: Got Trigger Interrupt message with vector 0xf3. 7175754217000: system.cpu00.interrupts: Interrupt is an Fixed. 7175754220500: system.cpu00.commit: Interrupt detected. 7175754220500
Re: [gem5-dev] Review Request 2524: config: Add two options for setting the kernel command line.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2524/#review5591 --- I do not see much value though, but I am fine with patch. configs/common/FSConfig.py http://reviews.gem5.org/r/2524/#comment5005 Should we make this function a part of SysConfig class? - Nilay Vaish On Nov. 23, 2014, 7:26 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2524/ --- (Updated Nov. 23, 2014, 7:26 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10561:b2a85a0c0571 --- config: Add two options for setting the kernel command line. Both options accept template which will, through python string formatting, have mem, disk, and script values substituted in from the mdesc. Additional values can be used on a case by case basis by passing them as keyword arguments to the fillInCmdLine function. That makes it possible to have specialized parameters for a particular ISA, for instance. The first option lets you specify the template directly, and the other lets you specify a file which has the template in it. Diffs - configs/common/FSConfig.py 6317351a288c0349c5855c7431bc1eeade61605c configs/common/Options.py 6317351a288c0349c5855c7431bc1eeade61605c configs/example/fs.py 6317351a288c0349c5855c7431bc1eeade61605c Diff: http://reviews.gem5.org/r/2524/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Patches ready to go
The problem is that Andreas has not added a new mem-type to configs/common/MemConfig.py. There should be a GDDR5 entry in the memory aliases map. Joel, add one yourself and provide the added type with --mem-type option. I think everything would work out fine. -- Nilay On Sat, 29 Nov 2014, Andreas Hansson via gem5-dev wrote: Hi Joel, The patch only adds a new dram config to DRAMCtrl.py, and there are no dependencies. I am not using Ruby myself, so I do not know what it involves to use this with Ruby. Perhaps Nilay can help? Could you just check that it matches your expectation at this point? Thanks, Andreas From: gem5-dev [gem5-dev-boun...@gem5.org] On Behalf Of Joel Hestness via gem5-dev [gem5-dev@gem5.org] Sent: Saturday, November 29, 2014 7:49 PM To: gem5 Developer List Subject: Re: [gem5-dev] Patches ready to go Hi Andreas, # DRAM config updates http://reviews.gem5.org/r/2489/ I'm having a lot of trouble figuring out which patches are required to get the GDDR5 DRAM config to apply. Can you let me know which pieces/parts are required to use this (preferably with Ruby)? Thanks, Joel -- Joel Hestness PhD Candidate, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://pages.cs.wisc.edu/~hestness/ ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] ELF image loader in x86 multiboot
A couple of things that might help. First, I think x86 32-bit support is only available in system call emulation mode. For 32-bit x86 full system, you probably will have to make significant changes to gem5. Second, since you are not able to boot a single kernel, I don't see the point of going for multiboot. In fact, I am unable to think of any benefits that multiboot would provide. On an actual system, it takes time to install a kernel and if things go wrong, you would want to switch back to some working version. With a simulator, you can maintain different kernel versions somewhere, and supply the right path to the simulator. -- Nilay On Thu, 27 Nov 2014, Randolf Rotta via gem5-dev wrote: Hello, my research group is working on lightweight operating systems for many-core processors. We are looking for a full system simulator that supports debugging of x86-64 code and processor state. Qemu does not tell much about the cpu state and the Bochs debugger has problems with addresses in the high 64bit kernel-space. Hence, gem5 is very interesting for us. Unfortunately, we are not able to boot our kernel ELF images at the moment. I applied the x86 32bit multiboot patches from https://bitbucket.org/chrism333/gem5-patches/src/ and adapted the gem5 configuration successfully. Now gem5 tries to load the ELF image via sim/system.cc, which ends up in ElfObject::loadSections and does fancy things with virtual addresses and hard-coded section names. The ELF loader is surely doing the correct thing to load 64bit user-space applications. But during the multiboot startup it should really just load all LOAD segments to the requested physical addresses and leave everything else alone -- especially virtual addresses. Assuming that I am able to implement such a simplified ELF loader for kernel images, what is a good way to integrate it into the existing infrastructure? Is it mandatory to derive the class MultibootX86System (in arch/x86/multiboot/system.hh) from the class System (in sim/system.hh)? Best regards, Randolf Rotta For reference, our kernel ELF image looks like this: objdump -fph boot32.elf boot32.elf: file format elf32-i386 architecture: i386, flags 0x0012: EXEC_P, HAS_SYMS start address 0x00200058 Program Header: LOAD off0x0078 vaddr 0x0020 paddr 0x0020 align 2**3 filesz 0x03ed memsz 0x00206000 flags rwx LOAD off0x0480 vaddr 0x8100 paddr 0x0080 align 2**6 filesz 0xda90 memsz 0x00401000 flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .init 03ed 0020 0020 0078 2**3 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .initbss 00205000 00201000 00201000 0465 2**0 ALLOC 2 .text 9256 8100 0080 0480 2**1 CONTENTS, ALLOC, LOAD, READONLY, CODE 3 .rodata 0c4d 81009280 00809280 9700 2**6 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .eh_frame 3bb8 81009ed0 00809ed0 a350 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .init_array 0008 8100da88 0080da88 df08 2**3 CONTENTS, ALLOC, LOAD, DATA 6 .bss 003f3540 8100dac0 0080dac0 df10 2**6 ALLOC ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Issue with O3 and interrupts
Ok, I have not seen this problem, but I got the description below. So what's your suggestion on fixing the problem? Should we add a stack of pending interrupts instead of maintaining one single variable? -- Nilay On Wed, 26 Nov 2014, Castillo Villar, Emilio via gem5-dev wrote: Good evening, I am experiencing a weird issue with the O3CPU, X86 and the interrupt handling. I am running in FS mode and one simulation just experienced a weird hang. The simulated machine is doing an spinlock over a value that an interrupt handler writes. After some debug I found that when the APIC sends two interruptions to the cpu in a very short time window, the first interruption is completely ignored. It can not even complete a commit of the first instruction in the service routine before all its values get replaced by the next interrupt. After this interrupt completes, the execution goes back to the application code and do not execute the code for the first interrupt. The problem is that the Lapic has the vector of the first interruption in the ISR register as it gets restored after the second interruption completes. Therefore, it thinks that the cpu is currently processing that interruption, though the cpu went back to execute application code and will never clear this ISR register. The Lapic uses this ISR value to filter incoming interruptions and in several cases, it does not forward those to the cpu, leading to unattended interruptions and hangs. I have seen this behavior in the kernels' native_flush_tlb_others function when a page fault happens. The core in charge of executing it, sends an interrupt to all the other cores in the system and it does a loop checking that every cores receive the interruption. When each core receives the interruption, they just execute the associated handler and perform a write to a variable, notifying the sender that the interruption was processed and the tlb was flushed. The problem is that one of the cores is ignoring this interruption, which has a vector value of 0xf0. I found that this core lapic has a value of 0xf1 in the ISR, filtering every lower vector. s This 0xf1 vector value was set by an interruption that never got to execute because of the problem explained before, hence the interruption carrying the 0xf0 vector value will never be executed and the native_flush_tlb_others function will not complete. I just took a trace of the moment when the 0xf1 interruption gets dropped. The flags used where Exec, Commit, Faults: system.cpu00.interrupts: Interrupt 0xf1 sent to core. 7175754213000: External Interrupt: RIP 0x8027a0a0: vector 0xf1: #INTR 7175754213000: system.cpu00.interrupts: NEW IRR 0 NEW ISR f1. Now the interrupt 0xf3 gets to execute and drops all the first interruption. 7175754217000: system.cpu00.interrupts: Got Trigger Interrupt message with vector 0xf3. 7175754217000: system.cpu00.interrupts: Interrupt is an Fixed. 7175754220500: system.cpu00.commit: Interrupt detected. 7175754220500: system.cpu00.interrupts: Interrupt 0xf3 sent to core. 7175754220500: External Interrupt: RIP 0x8027a0a0: vector 0xf3: #INTR 7175754220500: system.cpu00.interrupts: NEW IRR 0 NEW ISR f3. It can be seen how for both interrupts the RIP is the same. The first committed instruction after all this sequence of events is 7175754228500: system.cpu00 T0 : @handle_mm_fault+992.32768 : Microcode_ROM : slli t4, t1, 0x4 : IntAlu : D=0x0f30 which indeed is from the 0xf3 interrupt. The cpu executes all the handler and then writes to the APIC EOI register 7175754418500: system.cpu00.interrupts: Writing Local APIC register 5 at offset 0xb0 as 0. 7175754418500: system.cpu00.interrupts: WRITING TO EOI NEW ISRV IS 0xf1 Here the APIC believes it is servicing the 0xf1 interrupt. However the cpu goes back to the code it was executing right before the 0xf1 interrupt, and never services it. I was wondering if someone has found this issue before. Thanks a lot for your time. Best regards, --- Emilio Castillo ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2503: config: SystemC Gem5Control top level additions
On Tue, 25 Nov 2014, Andreas Hansson wrote: On Nov. 25, 2014, 9:52 p.m., Nilay Vaish wrote: I don't know what are we trying to achieve by interfacing gem5 and SystemC. But the patch seems fine to me. I would think roughly 90% of all the SoC model components in the world are written using SystemC as it is the de facto modeling framework (and an IEEE standard). Thus, interfacing gem5 with SystemC opens up for a wide variety of use cases that were not possible before. Makes sense? If 90% of all SoC development is done using SystemC, why would you not want to write the entire simulator using SystemC? -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2494: mem: Assume all dynamic packet data is array allocated
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2494/#review5536 --- Ship it! Ship It! - Nilay Vaish On Nov. 17, 2014, 6:14 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2494/ --- (Updated Nov. 17, 2014, 6:14 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10544:b595245892d9 --- mem: Assume all dynamic packet data is array allocated This patch simplifies how we deal with dynamically allocated data in the packet, always assuming that it is array allocated, and hence should be array deallocated (delete[] as opposed to delete). The only uses of dataDynamic was in the Ruby testers, and these are now changed to use Packet::allocate or dataDynamicArray as appropriate. The ARRAY_DATA flag in the packet is removed accordingly. No defragmentation of the flags is done at this point, leaving a gap in the bit masks. Going forward I would suggest a name change to better reflect the semantics, perhaps: dataStatic - dataNoFree dataDynamic - dataToFree Diffs - src/cpu/testers/directedtest/InvalidateGenerator.cc 1a9e235cab09 src/cpu/testers/directedtest/SeriesRequestGenerator.cc 1a9e235cab09 src/cpu/testers/rubytest/Check.cc 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 src/mem/ruby/slicc_interface/AbstractController.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2494/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2495: mem: Add checks and explanation for assertMemInhibit usage
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2495/#review5537 --- src/mem/packet.hh http://reviews.gem5.org/r/2495/#comment4965 I suggest we change the name of this and other such functions from assert* to set*. If someone were to tell me just the name of the function, I would assume the function tests the mem inhibit property for being true, like the C assert() function does. I am guessing the name has been taken from usage we come across in texts on digital logic design. - Nilay Vaish On Nov. 17, 2014, 6:14 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2495/ --- (Updated Nov. 17, 2014, 6:14 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10545:cf2650519e34 --- mem: Add checks and explanation for assertMemInhibit usage Diffs - src/mem/cache/cache_impl.hh 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 Diff: http://reviews.gem5.org/r/2495/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2503: config: SystemC Gem5Control top level additions
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2503/#review5538 --- Ship it! I don't know what are we trying to achieve by interfacing gem5 and SystemC. But the patch seems fine to me. util/systemc/sc_gem5_control.hh http://reviews.gem5.org/r/2503/#comment4968 What is this version for? util/systemc/sc_gem5_control.hh http://reviews.gem5.org/r/2503/#comment4967 Can you elaborate on what an elaboration is? I am guessing it to be a SystemC term. util/systemc/sc_gem5_control.cc http://reviews.gem5.org/r/2503/#comment4966 I am not against this indentation, but I think the norm is to align the arguments vertically. - Nilay Vaish On Nov. 17, 2014, 6:18 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2503/ --- (Updated Nov. 17, 2014, 6:18 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10554:f6e35a3dcc8f --- config: SystemC Gem5Control top level additions This patch cleans up a few style issues and adds a few capabilities to the SystemC top level 'Gem5Control/Gem5System' mechanism. These include: 1) A space to store/retrieve a version string for a model 2) A mechanism for registering functions to be called at the end of elaboration to perform simulation setup tasks in SystemC 3) Adding setGDBRemotePort to the Gem5Control 4) Changing the sc_set_time_resolution behaviour to instead check that the SystemC time resolution is already acceptable Diffs - util/systemc/sc_gem5_control.hh 1a9e235cab09 util/systemc/sc_gem5_control.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2503/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2516: config: Add options to take/resume from SimPoint checkpoints
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2516/#review5539 --- I suggest the additions being made to the Simulation.py file be made by creating new functions. I think the run function is already too big and confusing. configs/common/Options.py http://reviews.gem5.org/r/2516/#comment4969 Can you explain why we need this separate option for restoring from a checkpoint taken using the take-simpoint-checkpoints? - Nilay Vaish On Nov. 20, 2014, 9:43 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2516/ --- (Updated Nov. 20, 2014, 9:43 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10548:abc6a8156083 --- config: Add options to take/resume from SimPoint checkpoints More documentation at http://gem5.org/Simpoints Steps to profile, generate, and use SimPoints with gem5: 1. To profile workload and generate SimPoint BBV file, use the following option: --simpoint-profile --simpoint-interval interval length Requires single Atomic CPU and fastmem. interval length is in number of instructions. 2. Generate SimPoint analysis using SimPoint 3.2 from UCSD. (SimPoint 3.2 not included with this flow.) 3. To take gem5 checkpoints based on SimPoint analysis, use the following option: --take-simpoint-checkpoint=simpoint file path,weight file path,interval length,warmup length simpoint file and weight file is generated by SimPoint analysis tool from UCSD. SimPoint 3.2 format expected. interval length and warmup length are in number of instructions. 4. To resume from gem5 SimPoint checkpoints, use the following option: --restore-simpoint-checkpoint -r N --checkpoint-dir simpoint checkpoint path N is (SimPoint index + 1). E.g., -r 1 will resume from SimPoint #0. Diffs - configs/common/Options.py b61dc895269a configs/common/Simulation.py b61dc895269a configs/example/fs.py b61dc895269a Diff: http://reviews.gem5.org/r/2516/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2517: x86: vnc: Add a VNC server to x86 systems.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2517/#review5543 --- Ship it! Ship It! - Nilay Vaish On Nov. 22, 2014, 11:39 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2517/ --- (Updated Nov. 22, 2014, 11:39 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10553:e09c0875ad33 --- x86: vnc: Add a VNC server to x86 systems. Diffs - configs/common/FSConfig.py 6317351a288c0349c5855c7431bc1eeade61605c Diff: http://reviews.gem5.org/r/2517/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2520: x86: i8042: Add VNC keyboard input support.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2520/#review5545 --- Ship it! Seems fine. - Nilay Vaish On Nov. 22, 2014, 1:32 p.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2520/ --- (Updated Nov. 22, 2014, 1:32 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10556:76e90695e93b --- x86: i8042: Add VNC keyboard input support. This fixes up and fleshes out the keyboard model within the i8042 so that it can return keyboard input realistically enough to satisfy the kernel. One notable change was to turn off the convertScanCodes bit. That bit basically enables a compatibility mode which makes the keyboard return scancodes from set 1 which the XT computer used. We want to turn off that translation so that we get scancode set 2, the standard set which was used by the AT computer. That's also what the existing X11 keycode = scancode function developed for ARM returns. Diffs - src/dev/x86/i8042.hh 6317351a288c0349c5855c7431bc1eeade61605c src/dev/x86/i8042.cc 6317351a288c0349c5855c7431bc1eeade61605c Diff: http://reviews.gem5.org/r/2520/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2519: x86: i8042: Give the keyboard controller a little TLC.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2519/#review5547 --- What's TLC and CL? - Nilay Vaish On Nov. 22, 2014, 1:32 p.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2519/ --- (Updated Nov. 22, 2014, 1:32 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10555:595f40e72481 --- x86: i8042: Give the keyboard controller a little TLC. This CL fixes a few minor bugs, and fills out the general implementation a bit so that it can more readily support actually returning keyboard input. Diffs - src/dev/x86/i8042.hh 6317351a288c0349c5855c7431bc1eeade61605c src/dev/x86/i8042.cc 6317351a288c0349c5855c7431bc1eeade61605c Diff: http://reviews.gem5.org/r/2519/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2523: config: Get rid of some extra spaces around default arguments.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2523/#review5549 --- Ship it! Ship It! - Nilay Vaish On Nov. 23, 2014, 7:25 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2523/ --- (Updated Nov. 23, 2014, 7:25 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10560:b66945a370f9 --- config: Get rid of some extra spaces around default arguments. Diffs - configs/common/FSConfig.py 6317351a288c0349c5855c7431bc1eeade61605c Diff: http://reviews.gem5.org/r/2523/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Protocol Specific Profiling
On Mon, 24 Nov 2014, Beckmann, Brad wrote: Hi Nilay, On July 24, 2013 you removed the RubySlice_Profiler.sm, RubySlicc_Profiler_interface.cc and RubySlicc_Profiler_interface.hh files. See changeset 9771:57aac1719f86. By removing those files, you removed the ability to provide protocol specific profiling. Your I think you need to define what you mean by protocol specific profiling. The .sm file just contained some function prototypes. The actual definitions were calling on the RubySystem to get the RubyProfiler, both of which can be instantiated only once. comment seems to suggest that you expect that all profile functions called by the .sm files to use functions defined in AbstractController. Is that correct? That solution doesn't seem very scalable and it will lead to a very large AbstractController definition (I'm quite surprised how much that file has grown in the past two years...20+ modifications). If you need a new statistic, it should be defined in the .sm file for the controller that needs the statistic. That would be protocol specific. Defining everything in a single place is not protocol specific. Do you see a better way to support protocol specific profiling? We could add back in the RubySlice_Profiler.sm, RubySlicc_Profiler_interface.cc and RubySlicc_Profiler_interface.hh files, but I understand the benefit to have the functions be defined on a per machine basis. If you want the previous setup back, you can bring it back. Otherwise you can add code to RubySlicc_Util.hh in fashion similar to RubySlicc_Profiler.hh. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Protocol Specific Profiling
On Tue, 25 Nov 2014, Beckmann, Brad wrote: Thanks Nilay for the prompt reply. An example of a protocol specific statistic would be if say in a region coherence protocol [Power et al.], I was profiling the latencies of downgrade request-acks and I wanted to do that for the cross-product of requestor and request type. That is just one example, there are a million different possible statistics one could imagine wanting to collect. The specific example isn't important, the important part is we need any easy way to add protocol specific statistic processing. In other words, I want to collect data that doesn't neatly match a current gem5 statistic type and instead requires some sort of C++ customization before being added to a static data type. I think you are using a map or vector of some type. I would probably make SLICC understand what those types are. If you don't want to go that way, then you will have to do something similar to the earlier setup. Prototype a function in one of the .sm files, then define it say in RubySlicc_Util.hh and add the corresponding variable in the Profiler class. I'm not advocating for the prior solution. I completely agree going through the RubySlicc_Profile files was not great, but it is better than going through the AbstractController. At least the RubySlicc_Profile files were only collecting profile features. The AbstractController is growing into a beast. Perhaps what I'm looking for is an AbstractProfiler class that we can offload the current profiling work done by the AbstractController. Going through the abstract controller can be another way. I am actually not worried about the size of the class, unless you think that some function or data member is unecessary. We can define a class with in the AbstractController if you are worried about the profiling variables. If I am counting correctly, there are just three of them right now. I like the work you've done to collate statistics from independent object instantiations to a common set of data structures. We need to work on how those data structures are printed out, but your overall approach seems great. It seems the real problem we have now is that the generated collateStats functions directly cast to the AbstractController, thus all the stat interface functions need to be in the AbstractController. Instead, we to generate a protocol specific controller profiler that perhaps inherits from a to-be-determined AbstractProfiler class. The Profiler class still exists. You can still define a globally visible function that calls on the profiler to store some statistic. This is what use to happen before. The only other way I can think of is to make SLICC understand the different data structures we want to work with and use them in .sm files. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2527: config: ruby: Get rid of an eval and an exec operating on generated code.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2527/#review5521 --- Ship it! Ship It! - Nilay Vaish On Nov. 23, 2014, 11:03 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2527/ --- (Updated Nov. 23, 2014, 11:03 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10564:b90448378de5 --- config: ruby: Get rid of an eval and an exec operating on generated code. We can get the same result using importlib. Diffs - configs/ruby/Ruby.py 6317351a288c0349c5855c7431bc1eeade61605c Diff: http://reviews.gem5.org/r/2527/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2501: cpu: Move the packet deallocations out in the O3 CPU
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2501/#review5522 --- Ship it! I don't think out in is correct usage. - Nilay Vaish On Nov. 17, 2014, 6:18 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2501/ --- (Updated Nov. 17, 2014, 6:18 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10551:74b409fc3dd6 --- cpu: Move the packet deallocations out in the O3 CPU Move the packet deallocations out in the O3 CPU so that the completeDataAccess deals only with the LSQ specific parts and the generic recvTimingResp frees the packet. Diffs - src/cpu/o3/lsq_impl.hh 1a9e235cab09 src/cpu/o3/lsq_unit_impl.hh 1a9e235cab09 Diff: http://reviews.gem5.org/r/2501/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2502: cpu, o3: Ignored invalidate causing same-address load reordering
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2502/#review5523 --- In the last paragraph for the commit message, you metion second load. Replace it with later load since that is what you use in the rest of the message. src/arch/alpha/locked_mem.hh http://reviews.gem5.org/r/2502/#comment4960 Can we put this and the next hunk in a separate patch? It should be asserted in the commit message and the necessary source files that each ISA which implements these functions needs to compute the snoop address in the following manner. src/cpu/o3/lsq_impl.hh http://reviews.gem5.org/r/2502/#comment4961 But are you not losing the fault set by completeAcc()? - Nilay Vaish On Nov. 17, 2014, 6:18 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2502/ --- (Updated Nov. 17, 2014, 6:18 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10552:3056b69da027 --- cpu, o3: Ignored invalidate causing same-address load reordering In case the memory subsystem sends a combined response with invalidate (e.g. ReadRespWithInvalidate), we cannot ignore the invalidate part of the response. If we were to ignore the invalidate part, under certain circumstances this effectively leads to reordering of loads to the same address which is not permitted under any memory consistency model implemented in gem5. Consider the case where a later load's address is computed before an earlier load in program order, and is therefore sent to the memory subsystem first. At some point the earlier load's address is computed and in doing so correctly marks the later load as a possibleLoadViolation. In the meantime some other node writes and sends invalidations to all other nodes. The invalidation races with the later load's ReadResp, and arrives before ReadResp and is deferred. Upon receipt of the ReadResp, the response is changed to ReadRespWithInvalidate, and sent to the CPU. If we ignore the invalidate part of the packet, we let the later load read the old value of the address. Eventually the earlier load's ReadResp arrives, but with new data. As there was no invalidate snoop (sunk into the ReadRespWithInvalidate), and if we did not process the invalidate of the ReadRespWithInvalidate, we obtain a load reordering. A similar scenario can be constructed where the earlier load's address is computed after ReadRespWithInvalidate arrives for the younger load. In this case hitExternalSnoop needs to be set to true on the ReadRespWithInvalidate, so that upon knowing the address of the earlier load, checkViolations will cause the later load to be squashed. Finally we must account for the case where both loads are sent to the memory subsystem (reordered), a snoop invalidate arrives and correctly sets the later loads fault to ReExec. However, before the CPU processes the fault, the second load's ReadResp arrives and the writeback discards the outstanding fault. We must add a check to ensure that we do not skip any unprocessed faults. Diffs - src/arch/alpha/locked_mem.hh 1a9e235cab09 src/arch/mips/locked_mem.hh 1a9e235cab09 src/cpu/o3/lsq_impl.hh 1a9e235cab09 src/cpu/o3/lsq_unit_impl.hh 1a9e235cab09 Diff: http://reviews.gem5.org/r/2502/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2527: config: ruby: Get rid of an eval and an exec operating on generated code.
On Sun, 23 Nov 2014, Andreas Hansson via gem5-dev wrote: Hi all, I strongly suggest to not go beyond 2.6 at the moment. All Ubuntu 12.04 machines and RHE6 machines have 2.6 as their default, and that matches with our previous assumptions also regarding gcc etc. I agree with Steve that we can consider a move to 2.7, but it should be for stronger reasons that saving a few lines of code. I suggest we revert the change for now. I want to keep the changeset for a little while and see if users complain about it. The versions of Linux you mention are going to be around for a significant amount of time, so I do not want to base my decision on their lifetime. If any organization is internally using those Linux and it is hard for the users to move to python 2.7, then we should revert the changeset immediately. Otherwise, I prefer waiting for the first user complaint. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2497: mem: Make the requests carried by packets const
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2497/#review5502 --- src/mem/cache/cache_impl.hh http://reviews.gem5.org/r/2497/#comment4951 Why do we need the allocate() call? Since we know what the request is, can we not perform the allocation in the constructor itself? - Nilay Vaish On Nov. 17, 2014, 6:15 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2497/ --- (Updated Nov. 17, 2014, 6:15 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10547:e8cae196bce7 --- mem: Make the requests carried by packets const This adds a basic level of sanity checking to the packet by ensuring that a request is not modified once the packet is created. The only issue that had to be worked around is the relaying of software-prefetches in the cache. The specific situation is now solved by first copying the request, and then creating a new packet accordingly. Diffs - src/mem/cache/cache_impl.hh 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 Diff: http://reviews.gem5.org/r/2497/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2496: mem: Make Request getters const
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2496/#review5501 --- Ship it! Ship It! - Nilay Vaish On Nov. 17, 2014, 6:14 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2496/ --- (Updated Nov. 17, 2014, 6:14 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10546:af66f33b7d3a --- mem: Make Request getters const This patch tidies up the Request class, making all getters const. The odd one out is incAccessDepth which is called by the memory system as packets carry the request around. This is also const to enable the packet to hold on to a const Request. Diffs - src/mem/request.hh 1a9e235cab09 Diff: http://reviews.gem5.org/r/2496/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2498: mem: Cleanup Packet::checkFunctional and hasData usage
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2498/#review5506 --- Ship it! src/mem/packet.hh http://reviews.gem5.org/r/2498/#comment4954 Object of type Printable? Should this not be something else? - Nilay Vaish On Nov. 17, 2014, 6:16 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2498/ --- (Updated Nov. 17, 2014, 6:16 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10548:2b33b6c6b656 --- mem: Cleanup Packet::checkFunctional and hasData usage This patch cleans up the use of hasData and checkFunctional in the packet. The latter function is also tidied up to avoid name overloading. Diffs - src/mem/cache/cache_impl.hh 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 src/mem/packet.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2498/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2500: mem: Relax packet src/dest check and shift onus to crossbar
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2500/#review5508 --- Ship it! Ship It! - Nilay Vaish On Nov. 17, 2014, 6:17 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2500/ --- (Updated Nov. 17, 2014, 6:17 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10550:7636a5c1b905 --- mem: Relax packet src/dest check and shift onus to crossbar This patch allows objects to get the src/dest of a packet even if it is not set to a valid port id. This simplifies (ab)using the bridge as a buffer and latency adapter in situations where the neighbouring MemObjects are not crossbars. The checks that were done in the packet are now shifted to the crossbar where the fields are used to index into the port arrays. Thus, the carrier of the information is not burdened with checking, and the crossbar can check not only that the destination is set, but also that the port index is within limits. Diffs - src/mem/bridge.cc 1a9e235cab09 src/mem/cache/cache_impl.hh 1a9e235cab09 src/mem/coherent_xbar.cc 1a9e235cab09 src/mem/noncoherent_xbar.cc 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 Diff: http://reviews.gem5.org/r/2500/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2491: mem: Add const getters for write packet data
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2491/#review5467 --- src/mem/packet.hh http://reviews.gem5.org/r/2491/#comment4917 I think we can keep the function name as getPtr() and rely on the compiler to pick the right version. Also how about const_castT* instead of C style casting? - Nilay Vaish On Nov. 17, 2014, 6:13 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2491/ --- (Updated Nov. 17, 2014, 6:13 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10541:d68e4d58597b --- mem: Add const getters for write packet data This patch takes a first step in tightening up how we use the data pointer in write packets. A const getter is added for the pointer itself (getConstPtr), and a number of member functions are also made const accordingly. In a range of places throughout the memory system the new member is used. Diffs - src/cpu/inorder/resources/cache_unit.cc 1a9e235cab09 src/cpu/inorder/resources/fetch_unit.cc 1a9e235cab09 src/cpu/minor/execute.cc 1a9e235cab09 src/cpu/minor/lsq.cc 1a9e235cab09 src/cpu/o3/fetch_impl.hh 1a9e235cab09 src/cpu/simple/atomic.cc 1a9e235cab09 src/cpu/testers/memtest/memtest.cc 1a9e235cab09 src/cpu/testers/rubytest/Check.cc 1a9e235cab09 src/mem/abstract_mem.cc 1a9e235cab09 src/mem/cache/cache.hh 1a9e235cab09 src/mem/cache/cache_impl.hh 1a9e235cab09 src/mem/external_slave.cc 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 src/mem/packet.cc 1a9e235cab09 src/mem/packet_access.hh 1a9e235cab09 src/mem/ruby/common/DataBlock.hh 1a9e235cab09 src/mem/ruby/common/DataBlock.cc 1a9e235cab09 src/mem/ruby/slicc_interface/RubyRequest.cc 1a9e235cab09 src/mem/ruby/slicc_interface/RubySlicc_Util.hh 1a9e235cab09 src/mem/ruby/system/Sequencer.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2491/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2490: mem: Remove null-check bypassing in Packet::getPtr
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2490/#review5469 --- Overall I am fine with the patch. Can we set the size to 1 when the prefetch request is being created? I don't see any harm in that. src/mem/ruby/system/Sequencer.cc http://reviews.gem5.org/r/2490/#comment4919 Typo in prefetche. - Nilay Vaish On Nov. 17, 2014, 6:13 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2490/ --- (Updated Nov. 17, 2014, 6:13 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10540:0d0fabda59bd --- mem: Remove null-check bypassing in Packet::getPtr This patch removes the parameter that enables bypassing the null check in the Packet::getPtr method. A number of call sites assume the value to be non-null. The one odd case is the RubyTester, which issues zero-sized prefetches(!), and despite being reads they had no valid data pointer. This is now fixed, but the size oddity remains (unless anyone object or has any good suggestions). Finally, in the Ruby Sequencer, appropriate checks are made for flush packets as they have no valid data pointer. Diffs - src/cpu/testers/rubytest/Check.cc 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 src/mem/ruby/slicc_interface/RubyRequest.cc 1a9e235cab09 src/mem/ruby/slicc_interface/RubySlicc_Util.hh 1a9e235cab09 src/mem/ruby/system/DMASequencer.cc 1a9e235cab09 src/mem/ruby/system/Sequencer.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2490/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] bug? in elf loader
I checked the elf-64 draft and I think you right. But I am not able to
understand why do we use p_paddr at all. Should we not be using p_vaddr
everywhere?
--
Nilay
On Tue, 18 Nov 2014, Romana, Alexandre via gem5-dev wrote:
Hi everybody,
Looks to me like there is a bug/typo in elf_loader.cc:
318 // Check to see if this segment contains the bss section.
319 if (phdr.p_paddr = bssSecStart
320 phdr.p_paddr + phdr.p_memsz bssSecStart
321 phdr.p_memsz - phdr.p_filesz 0) {
322 bss.baseAddr = phdr.p_paddr + phdr.p_filesz;
323 bss.size = phdr.p_memsz - phdr.p_filesz;
324 bss.fileImage = NULL;
325 }
326
327 // Check to see if this is the text or data segment
328 if (phdr.p_vaddr = textSecStart
329 phdr.p_vaddr + phdr.p_filesz textSecStart) {
330 text.baseAddr = phdr.p_paddr;
331 text.size = phdr.p_filesz;
332 text.fileImage = fileData + phdr.p_offset;
333 } else if (phdr.p_vaddr = dataSecStart
334 phdr.p_vaddr + phdr.p_filesz dataSecStart) {
335 data.baseAddr = phdr.p_paddr;
336 data.size = phdr.p_filesz;
337 data.fileImage = fileData + phdr.p_offset;
338 } else {
339 // If it's none of the above but is loadable,
340 // load the filesize worth of data
341 Segment extra;
342 extra.baseAddr = phdr.p_paddr;
343 extra.size = phdr.p_filesz;
344 extra.fileImage = fileData + phdr.p_offset;
345 extraSegments.push_back(extra);
I guess nobody used so far the loader with the bss section mapped onto a
segment with different virtual and physical addresses…
To double check you can look at the bssSecStart definition:
bssSecStart = shdr.sh_addr;
sh_addr being the virtual address, I think we can safely assume there’s a typo
line 319-320, and I can submit a patch (changing 2 characters in the code),
or could anybody please explain why we are comparing virtual with physical
addresses here?
Thanks,
Alexandre
Texas Instruments France SAS, Immeuble Le Khapa, 65 Quai Georges Gorse, ZAC
Seguin Rives de Seine, 92100 Boulogne Billancourt. 036 420 040 R.C.S Nanterre.
Capital de EUR 12.654.784
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2492: mem: Use const pointers for port proxy write functions
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2492/#review5475 --- Ship it! Ship It! - Nilay Vaish On Nov. 17, 2014, 6:14 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2492/ --- (Updated Nov. 17, 2014, 6:14 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10542:6cbdd036f4b9 --- mem: Use const pointers for port proxy write functions This patch changes the various write functions in the port proxies to use const pointers for all sources (similar to how memcpy works). The one unfortunate aspect is the need for a const_cast in the packet, to avoid having to juggle a const and a non-const data pointer. This design decision can always be re-evaluated at a later stage. Diffs - src/mem/fs_translating_port_proxy.hh 1a9e235cab09 src/mem/fs_translating_port_proxy.cc 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 src/mem/port_proxy.hh 1a9e235cab09 src/mem/port_proxy.cc 1a9e235cab09 src/mem/se_translating_port_proxy.hh 1a9e235cab09 src/mem/se_translating_port_proxy.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2492/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2491: mem: Add const getters for write packet data
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2491/#review5477 --- Ship it! Ship It! - Nilay Vaish On Nov. 17, 2014, 6:13 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2491/ --- (Updated Nov. 17, 2014, 6:13 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10541:d68e4d58597b --- mem: Add const getters for write packet data This patch takes a first step in tightening up how we use the data pointer in write packets. A const getter is added for the pointer itself (getConstPtr), and a number of member functions are also made const accordingly. In a range of places throughout the memory system the new member is used. Diffs - src/cpu/inorder/resources/cache_unit.cc 1a9e235cab09 src/cpu/inorder/resources/fetch_unit.cc 1a9e235cab09 src/cpu/minor/execute.cc 1a9e235cab09 src/cpu/minor/lsq.cc 1a9e235cab09 src/cpu/o3/fetch_impl.hh 1a9e235cab09 src/cpu/simple/atomic.cc 1a9e235cab09 src/cpu/testers/memtest/memtest.cc 1a9e235cab09 src/cpu/testers/rubytest/Check.cc 1a9e235cab09 src/mem/abstract_mem.cc 1a9e235cab09 src/mem/cache/cache.hh 1a9e235cab09 src/mem/cache/cache_impl.hh 1a9e235cab09 src/mem/external_slave.cc 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 src/mem/packet.cc 1a9e235cab09 src/mem/packet_access.hh 1a9e235cab09 src/mem/ruby/common/DataBlock.hh 1a9e235cab09 src/mem/ruby/common/DataBlock.cc 1a9e235cab09 src/mem/ruby/slicc_interface/RubyRequest.cc 1a9e235cab09 src/mem/ruby/slicc_interface/RubySlicc_Util.hh 1a9e235cab09 src/mem/ruby/system/Sequencer.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2491/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2491: mem: Add const getters for write packet data
On Nov. 18, 2014, 3:32 p.m., Nilay Vaish wrote: src/mem/packet.hh, line 860 http://reviews.gem5.org/r/2491/diff/1/?file=42506#file42506line860 I think we can keep the function name as getPtr() and rely on the compiler to pick the right version. Also how about const_castT* instead of C style casting? Andreas Hansson wrote: I'd actually prefer it to be explicit at this point if you don't mind. I has helped me figure out where we should be using const but cannot due to the way read/write is part of the same function, but with a bool is_read (which is currently done in a lot of devices for example). As you like it. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2491/#review5467 --- On Nov. 17, 2014, 6:13 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2491/ --- (Updated Nov. 17, 2014, 6:13 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10541:d68e4d58597b --- mem: Add const getters for write packet data This patch takes a first step in tightening up how we use the data pointer in write packets. A const getter is added for the pointer itself (getConstPtr), and a number of member functions are also made const accordingly. In a range of places throughout the memory system the new member is used. Diffs - src/cpu/inorder/resources/cache_unit.cc 1a9e235cab09 src/cpu/inorder/resources/fetch_unit.cc 1a9e235cab09 src/cpu/minor/execute.cc 1a9e235cab09 src/cpu/minor/lsq.cc 1a9e235cab09 src/cpu/o3/fetch_impl.hh 1a9e235cab09 src/cpu/simple/atomic.cc 1a9e235cab09 src/cpu/testers/memtest/memtest.cc 1a9e235cab09 src/cpu/testers/rubytest/Check.cc 1a9e235cab09 src/mem/abstract_mem.cc 1a9e235cab09 src/mem/cache/cache.hh 1a9e235cab09 src/mem/cache/cache_impl.hh 1a9e235cab09 src/mem/external_slave.cc 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 src/mem/packet.cc 1a9e235cab09 src/mem/packet_access.hh 1a9e235cab09 src/mem/ruby/common/DataBlock.hh 1a9e235cab09 src/mem/ruby/common/DataBlock.cc 1a9e235cab09 src/mem/ruby/slicc_interface/RubyRequest.cc 1a9e235cab09 src/mem/ruby/slicc_interface/RubySlicc_Util.hh 1a9e235cab09 src/mem/ruby/system/Sequencer.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2491/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2513: KVM: Build in most of the KVM stuff even if we're not going to use it.
On Tue, 18 Nov 2014, Steve Reinhardt via gem5-dev wrote: I haven't looked at the code in question, so I'm just going by what I've seen in this email thread. However, it seems like there ought to be some alternative solutions here. I like the general direction Andreas is going, though it would be nice to avoid more multiple inheritance :). The way I see it, the basic idea there is to create an API (either on an existing object like System or on a new object) that the device can call irrespective of whether KVM is configured or not, but which gives enough information to get the job done; then the other object can be responsible for either coordinating with KVM or (presumably) ignoring all those calls if KVM is not configured. As a simpler alternative, maybe we don't need to give the kvm pointer to the device via python; if the System object has an accessor that would return the vm pointer, then the device could call that during initialization, and it would of course just return NULL if kvm is not configured But would not this also cause the same problem that we cannot compile on systems that do not have kvm support? In Andreas' suggestion, we would be selectively compiling certain file(s) which should resolve the issue. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Memory directory structure
Brad, would not a couple of sed commands be enough for fixing paths in existing patches? I think we should let Andreas move slicc and protocol directory to ruby and he would provide a sed script that fixes everything. In fact, if we can, we should have things separated out into three directories: common (port stuff), classic and ruby. Common code can still reside in src/mem as it is currently. As far as the replicated components are concerned, I don't think it would be possible for one memory system to use what the other provides unless somebody is willing to make significant changes to at least one of the two systems. Note that classic does not understand ruby's messages and flits and ruby only partly understands what packets are. Therefore, Andreas can make an interconnect directory but that would contain only classic components for the time being. -- Nilay On Wed, 12 Nov 2014, Andreas Hansson via gem5-dev wrote: Hi Brad, I suspected there would be issues lurking. Mostly the benefit would be: 1) clarity for people not familiar with the code base, and 2) work towards building the entire memory system independent of the ISA (and put in a libmem.a or similar). If moving the directories is causing significant problems on your side then we can hold off. I am not sure I understand your second point. The Œclassic¹ memory system already has crossbars and snoop filters, I am merely suggesting to not have a big flat src/mem directory, but create some structure. Are you suggesting to put the Œclassic¹ components in src/mem/ruby? Andreas On 11/12/14, 12:06 AM, Beckmann, Brad via gem5-dev gem5-dev@gem5.org wrote: I understand that protocol and slicc directories are logically underneath Ruby, but I strongly content the small benefit of moving those directories does not justify the work it will create downstream. There is a lot of code that works on top of the current directory structure. I would really appreciate if we didn't make that change. Also Ruby already implements crossbars, snoop filters, and other interconnect/coherence structures. Why not just use those rather than add a new interconnect subdir? Brad -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay Vaish via gem5-dev Sent: Tuesday, November 11, 2014 3:37 PM To: Andreas Hansson via gem5-dev Subject: Re: [gem5-dev] Memory directory structure I am fine with the proposed changes. -- Nilay On Tue, 11 Nov 2014, Andreas Hansson via gem5-dev wrote: Hi all, I was contemplating adding a src/mem/ram subdirectory and put the DRAM and SimpleMemory files there. I would also like to propose to move src/mem/protocol and src/mem/slicc into the src/mem/ruby subdirectory as they are unique to Ruby. Does that make sense? It might be worth creating a src/mem/interconnect subdir as well for the crossbar, bridges, snoop filter etc. Thoughts? Andreas -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: stats: changes to x86 o3 fs and sparc fs regr...
changeset 533ec854b2f1 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=533ec854b2f1 description: stats: changes to x86 o3 fs and sparc fs regression tests. diffstat: tests/long/fs/10.linux-boot/ref/x86/linux/pc-o3-timing/stats.txt | 54 +- tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt | 334 +- 2 files changed, 194 insertions(+), 194 deletions(-) diffs (truncated from 541 to 300 lines): diff -r 05b5a6cf3521 -r 533ec854b2f1 tests/long/fs/10.linux-boot/ref/x86/linux/pc-o3-timing/stats.txt --- a/tests/long/fs/10.linux-boot/ref/x86/linux/pc-o3-timing/stats.txt Thu Nov 06 05:42:22 2014 -0600 +++ b/tests/long/fs/10.linux-boot/ref/x86/linux/pc-o3-timing/stats.txt Tue Nov 11 14:17:10 2014 -0600 @@ -4,11 +4,11 @@ sim_ticks5125902116500 # Number of ticks simulated final_tick 5125902116500 # Number of ticks from beginning of simulation (restored from checkpoints and never reset) sim_freq 1 # Frequency of simulated ticks -host_inst_rate 196886 # Simulator instruction rate (inst/s) -host_op_rate 389187 # Simulator op (including micro ops) rate (op/s) -host_tick_rate 2473535129 # Simulator tick rate (ticks/s) -host_mem_usage 743248 # Number of bytes of host memory used -host_seconds 2072.30 # Real time elapsed on the host +host_inst_rate 134346 # Simulator instruction rate (inst/s) +host_op_rate 265563 # Simulator op (including micro ops) rate (op/s) +host_tick_rate 1687822207 # Simulator tick rate (ticks/s) +host_mem_usage 793660 # Number of bytes of host memory used +host_seconds 3036.99 # Real time elapsed on the host sim_insts 408006726 # Number of instructions simulated sim_ops 806511598 # Number of ops (including micro ops) simulated system.voltage_domain.voltage 1 # Voltage in Volts @@ -630,36 +630,36 @@ system.cpu.rename.LQFullEvents 181319 # Number of times rename has blocked due to LQ full system.cpu.rename.SQFullEvents 13705397 # Number of times rename has blocked due to SQ full system.cpu.rename.RenamedOperands 997542850 # Number of destination operands rename has renamed -system.cpu.rename.RenameLookups1813799496 # Number of register rename lookups that rename has made -system.cpu.rename.int_rename_lookups 1115056771 # Number of integer rename lookups +system.cpu.rename.RenameLookups1813799502 # Number of register rename lookups that rename has made +system.cpu.rename.int_rename_lookups 1115056777 # Number of integer rename lookups system.cpu.rename.fp_rename_lookups 257 # Number of floating rename lookups system.cpu.rename.CommittedMaps 964533940 # Number of HB maps that are committed system.cpu.rename.UndoneMaps 33008908 # Number of HB maps that are undone due to squashing system.cpu.rename.serializingInsts 469072 # count of serializing insts renamed system.cpu.rename.tempSerializingInsts 473209 # count of temporary serializing insts renamed system.cpu.rename.skidInsts 39003947 # count of insts added to the skid buffer -system.cpu.memDep0.insertedLoads 17327061 # Number of loads inserted to the mem dependence unit. +system.cpu.memDep0.insertedLoads 17327064 # Number of loads inserted to the mem dependence unit. system.cpu.memDep0.insertedStores10187947 # Number of stores inserted to the mem dependence unit. system.cpu.memDep0.conflictingLoads 1305152 # Number of conflicting loads. system.cpu.memDep0.conflictingStores 1075480 # Number of conflicting stores. -system.cpu.iq.iqInstsAdded 829577981
Re: [gem5-dev] Memory directory structure
I am fine with the proposed changes. -- Nilay On Tue, 11 Nov 2014, Andreas Hansson via gem5-dev wrote: Hi all, I was contemplating adding a src/mem/ram subdirectory and put the DRAM and SimpleMemory files there. I would also like to propose to move src/mem/protocol and src/mem/slicc into the src/mem/ruby subdirectory as they are unique to Ruby. Does that make sense? It might be worth creating a src/mem/interconnect subdir as well for the crossbar, bridges, snoop filter etc. Thoughts? Andreas -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2469: mem: dram ctrl: correct errors due to busBusyUntil variable
As I suggested before, we will keep the timing accesses to ruby and the dram ctrl would be accessed using functional accesses. -- Nilay On Sun, 9 Nov 2014, Andreas Hansson via gem5-dev wrote: Hi Brad, Thanks a lot for the clarification. It seems the cleanest way (although that is probably requiring a lot of work), would be to do this playback without any timing involved, e.g. using atomic accesses and ignoring all return values, and doing so just after all other startup activity is done, perhaps in a new ??playbackState?? or something along those lines. In any case, for the short term, let me know if you need any help with a work-around Nilay. I??d prefer to discard the patch you currently have on RB and solve it some other way. Thanks, Andreas On 11/6/14, 6:10 PM, Beckmann, Brad via gem5-dev gem5-dev@gem5.org wrote: Andreas, we record the owner of the cache block in the trace. This methodology simplifies the configuration dependencies on the checkpoint and has worked well for Ruby for 15 years. There is actually an old paper from MIT that describes a more complete way of recording the owner of a cache block (I don't recall the author). It is quite a bit more complicated than what we do in Ruby today. Brad -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson via gem5-dev Sent: Thursday, November 06, 2014 9:49 AM To: Nilay Vaish Cc: Default Subject: Re: [gem5-dev] Review Request 2469: mem: dram ctrl: correct errors due to busBusyUntil variable Hi Nilay, It seem like a bit of a hack to do timing within Ruby and functional to the memory, but it will probably serve as a work-around. I??m actually intrigued now how we do this recording/replaying of the cache traces. Does it really make sense to do it this way? If the cache config is the same, we could have just saved the state. If the config is different, how would we know what to play back where? Does it really restore to any sensible state? Andreas On 06/11/2014 17:45, Nilay Vaish ni...@cs.wisc.edu wrote: On Thu, 6 Nov 2014, Andreas Hansson wrote: Hi Nilay, I would really not like us to introduce yet another step in the initialisation process unless it is absolutely necessary. The steps done in the DRAM controller relies on curTick being set correctly, and to the best of my knowledge the first opportunity to do this is startup. I would prefer to stick to the rule that only functional transactions are allowed up till this point. We will not be able to load the checkpointed state only with functional reads and writes since functional accesses do not update coherence states in ruby controllers. But it seems we can limit timing accesses to the ruby portion and perform functional accesses to the dram. This should allow use to keep the dram ctrl same as it is now. I think the best solution would be if Ruby would load its state in loadState/unserialize without using timing transactions, but I do not have a good suggestion for how to make this happen. Additionally, how do we even know what transactions to play back when it is done in startup today? We just issue read for all the addresses that are part of the checkpointed cache state. -- Nilay -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2209: ruby: single physical memory in fs mode
On Sun, 9 Nov 2014, George Voicu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2209/#review5449 --- The connection of the ruby io port to the PIO bus in fs.py (line 167) should be done only once, outside of the cpus for loop. You are right. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] There seems a bug in ruby/mesi_three_level.py
You should post your changes as patch on the review board (reviews.gem5.org). From the code the below, I am unable to find the lines changed. -- Nilay On Fri, 7 Nov 2014, nifan via gem5-dev wrote: Hi: I believe there is a bug in MESI_Three_Level.py. when I tried to run build/MESI_Three_Level/gem5.debug config/example/fs.py --ruby I got a segment fault, I track the code and found it occurs in the initfunction in DMA_Controller.cc, after careful comparision with MESI_Two_Level. I modified ruby/mesi_three_level.py as follows, the original code : 215 exec(ruby_system.dma_cntrl%d = dma_cntrl % i) 216 exec(ruby_system.dma_cntrl%d.dma_sequencer.slave = dma_port % i) 217 dma_cntrl_nodes.append(dma_cntrl) 218 219 all_cntrls = l0_cntrl_nodes + \ Two lines are added as marked red. 194 exec(ruby_system.dma_cntrl%d = dma_cntrl % i) 195 dma_cntrl_nodes.append(dma_cntrl) 196 197 # Connect the dma controller to the network 198 dma_cntrl.responseFromDir = ruby_system.network.master 199 dma_cntrl.requestToDir = ruby_system.network.slave 200 201 all_cntrls = l1_cntrl_nodes + \ After the modification, every thing goes fine. IS it a real bug or it happens just because I missed something? can anyone confirm it, thanks a lot. --- From Tommy ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: ruby: remove sparse memory.
changeset 7740e0d97d48 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=7740e0d97d48
description:
ruby: remove sparse memory.
In my opinion, it creates needless complications in rest of the code.
Also, this structure hinders the move towards common set of code for
physical memory controllers.
diffstat:
src/mem/ruby/structures/DirectoryMemory.cc | 87 +
src/mem/ruby/structures/DirectoryMemory.hh |9 -
src/mem/ruby/structures/SConscript |1 -
src/mem/ruby/structures/SparseMemory.cc| 417 -
src/mem/ruby/structures/SparseMemory.hh| 98 --
src/mem/ruby/system/System.cc | 30 +-
src/mem/ruby/system/System.hh |3 -
7 files changed, 22 insertions(+), 623 deletions(-)
diffs (truncated from 803 to 300 lines):
diff -r 7a3ad4b09ce4 -r 7740e0d97d48 src/mem/ruby/structures/DirectoryMemory.cc
--- a/src/mem/ruby/structures/DirectoryMemory.ccThu Nov 06 05:41:44
2014 -0600
+++ b/src/mem/ruby/structures/DirectoryMemory.ccThu Nov 06 05:42:20
2014 -0600
@@ -47,8 +47,6 @@
m_size_bytes = p-size;
m_size_bits = floorLog2(m_size_bytes);
m_num_entries = 0;
-m_use_map = p-use_map;
-m_map_levels = p-map_levels;
m_numa_high_bit = p-numa_high_bit;
}
@@ -56,16 +54,10 @@
DirectoryMemory::init()
{
m_num_entries = m_size_bytes / RubySystem::getBlockSizeBytes();
-
-if (m_use_map) {
-m_sparseMemory = new SparseMemory(m_map_levels);
-g_system_ptr-registerSparseMemory(m_sparseMemory);
-} else {
-m_entries = new AbstractEntry*[m_num_entries];
-for (int i = 0; i m_num_entries; i++)
-m_entries[i] = NULL;
-m_ram = g_system_ptr-getMemoryVector();
-}
+m_entries = new AbstractEntry*[m_num_entries];
+for (int i = 0; i m_num_entries; i++)
+m_entries[i] = NULL;
+m_ram = g_system_ptr-getMemoryVector();
m_num_directories++;
m_num_directories_bits = ceilLog2(m_num_directories);
@@ -80,16 +72,12 @@
DirectoryMemory::~DirectoryMemory()
{
// free up all the directory entries
-if (m_entries != NULL) {
-for (uint64 i = 0; i m_num_entries; i++) {
-if (m_entries[i] != NULL) {
-delete m_entries[i];
-}
+for (uint64 i = 0; i m_num_entries; i++) {
+if (m_entries[i] != NULL) {
+delete m_entries[i];
}
-delete [] m_entries;
-} else if (m_use_map) {
-delete m_sparseMemory;
}
+delete [] m_entries;
}
uint64
@@ -130,13 +118,9 @@
assert(isPresent(address));
DPRINTF(RubyCache, Looking up address: %s\n, address);
-if (m_use_map) {
-return m_sparseMemory-lookup(address);
-} else {
-uint64_t idx = mapAddressToLocalIdx(address);
-assert(idx m_num_entries);
-return m_entries[idx];
-}
+uint64_t idx = mapAddressToLocalIdx(address);
+assert(idx m_num_entries);
+return m_entries[idx];
}
AbstractEntry*
@@ -146,60 +130,21 @@
uint64 idx;
DPRINTF(RubyCache, Looking up address: %s\n, address);
-if (m_use_map) {
-m_sparseMemory-add(address, entry);
-entry-changePermission(AccessPermission_Read_Write);
-} else {
-idx = mapAddressToLocalIdx(address);
-assert(idx m_num_entries);
-entry-getDataBlk().assign(m_ram-getBlockPtr(address));
-entry-changePermission(AccessPermission_Read_Only);
-m_entries[idx] = entry;
-}
+idx = mapAddressToLocalIdx(address);
+assert(idx m_num_entries);
+entry-getDataBlk().assign(m_ram-getBlockPtr(address));
+entry-changePermission(AccessPermission_Read_Only);
+m_entries[idx] = entry;
return entry;
}
void
-DirectoryMemory::invalidateBlock(PhysAddress address)
-{
-if (m_use_map) {
-assert(m_sparseMemory-exist(address));
-m_sparseMemory-remove(address);
-}
-#if 0
-else {
-assert(isPresent(address));
-
-int64 index = address.memoryModuleIndex();
-
-if (index 0 || index m_size) {
-ERROR_MSG(Directory Memory Assertion:
- accessing memory out of range.);
-}
-
-if (m_entries[index] != NULL){
-delete m_entries[index];
-m_entries[index] = NULL;
-}
-}
-#endif
-}
-
-void
DirectoryMemory::print(ostream out) const
{
}
void
-DirectoryMemory::regStats()
-{
-if (m_use_map) {
-m_sparseMemory-regStats(name());
-}
-}
-
-void
DirectoryMemory::recordRequestType(DirectoryRequestType requestType) {
DPRINTF(RubyStats, Recorded statistic: %s\n,
DirectoryRequestType_to_string(requestType));
diff -r 7a3ad4b09ce4 -r 7740e0d97d48 src/mem/ruby/structures/DirectoryMemory.hh
--- a/src/mem/ruby/structures/DirectoryMemory.hhThu Nov 06 05:41:44
2014 -0600
+++ b/src/mem/ruby/structures/DirectoryMemory.hh
[gem5-dev] changeset in gem5: ruby: remove the function functionalReadBuffe...
changeset 5777a3e55603 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=5777a3e55603
description:
ruby: remove the function functionalReadBuffers()
This function was added when I had incorrectly arrived at the conclusion
that such a function can improve the chances of a functional read
succeeding.
As was later realized, this is not possible in the current setup.
While the
code using this function was dropped long back, this function was not.
Hence
the patch.
diffstat:
src/mem/ruby/slicc_interface/AbstractController.hh | 7 +
src/mem/slicc/symbols/StateMachine.py | 24 --
2 files changed, 2 insertions(+), 29 deletions(-)
diffs (58 lines):
diff -r 13312d6e1caf -r 5777a3e55603
src/mem/ruby/slicc_interface/AbstractController.hh
--- a/src/mem/ruby/slicc_interface/AbstractController.hhThu Nov 06
05:42:20 2014 -0600
+++ b/src/mem/ruby/slicc_interface/AbstractController.hhThu Nov 06
05:42:20 2014 -0600
@@ -76,11 +76,8 @@
virtual void recordCacheTrace(int cntrl, CacheRecorder* tr) = 0;
virtual Sequencer* getSequencer() const = 0;
-//! These functions are used by ruby system to read/write the message
-//! queues that exist with in the controller.
-//! The boolean return value indicates if the read was performed
-//! successfully.
-virtual bool functionalReadBuffers(PacketPtr) = 0;
+//! These functions are used by ruby system to read/write the data blocks
+//! that exist with in the controller.
virtual void functionalRead(const Address addr, PacketPtr) = 0;
//! The return value indicates the number of messages written with the
//! data from the packet.
diff -r 13312d6e1caf -r 5777a3e55603 src/mem/slicc/symbols/StateMachine.py
--- a/src/mem/slicc/symbols/StateMachine.py Thu Nov 06 05:42:20 2014 -0600
+++ b/src/mem/slicc/symbols/StateMachine.py Thu Nov 06 05:42:20 2014 -0600
@@ -285,7 +285,6 @@
void recordCacheTrace(int cntrl, CacheRecorder* tr);
Sequencer* getSequencer() const;
-bool functionalReadBuffers(PacketPtr);
uint32_t functionalWriteBuffers(PacketPtr);
void countTransition(${ident}_State state, ${ident}_Event event);
@@ -988,29 +987,6 @@
for func in self.functions:
code(func.generateCode())
-# Function for functional reads from messages buffered in the
controller
-code('''
-bool
-$c_ident::functionalReadBuffers(PacketPtr pkt)
-{
-''')
-for var in self.objects:
-vtype = var.type
-if vtype.isBuffer:
-vid = m_%s_ptr % var.ident
-code('if ($vid-functionalRead(pkt)) { return true; }')
-
-for var in self.config_parameters:
-vtype = var.type_ast.type
-if vtype.isBuffer:
-vid = m_%s_ptr % var.ident
-code('if ($vid-functionalRead(pkt)) { return true; }')
-
-code('''
-return false;
-}
-''')
-
# Function for functional writes to messages buffered in the controller
code('''
uint32_t
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: ruby: dma sequencer: remove RubyPort as paren...
changeset 30e3715c9405 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=30e3715c9405
description:
ruby: dma sequencer: remove RubyPort as parent class
As of now DMASequencer inherits from the RubyPort class. But the code
in
RubyPort class is heavily tailored for the CPU Sequencer. There are
parts of
the code that are not required at all for the DMA sequencer. Moreover,
the
next patch uses the dma sequencer for carrying out memory accesses for
all the
io devices. Hence, it is better to have a leaner dma sequencer.
diffstat:
src/mem/ruby/system/DMASequencer.cc | 195 +++-
src/mem/ruby/system/DMASequencer.hh | 75 +-
src/mem/ruby/system/Sequencer.py| 13 +-
3 files changed, 274 insertions(+), 9 deletions(-)
diffs (truncated from 374 to 300 lines):
diff -r ba51f8572571 -r 30e3715c9405 src/mem/ruby/system/DMASequencer.cc
--- a/src/mem/ruby/system/DMASequencer.cc Mon Nov 03 10:14:42 2014 -0600
+++ b/src/mem/ruby/system/DMASequencer.cc Thu Nov 06 00:55:09 2014 -0600
@@ -28,26 +28,212 @@
#include memory
+#include debug/Config.hh
+#include debug/Drain.hh
#include debug/RubyDma.hh
#include debug/RubyStats.hh
#include mem/protocol/SequencerMsg.hh
-#include mem/protocol/SequencerRequestType.hh
#include mem/ruby/system/DMASequencer.hh
#include mem/ruby/system/System.hh
+#include sim/system.hh
DMASequencer::DMASequencer(const Params *p)
-: RubyPort(p)
+: MemObject(p), m_version(p-version), m_controller(NULL),
+ m_mandatory_q_ptr(NULL), m_usingRubyTester(p-using_ruby_tester),
+ slave_port(csprintf(%s.slave, name()), this, access_phys_mem, 0),
+ drainManager(NULL), system(p-system), retry(false),
+ access_phys_mem(p-access_phys_mem)
{
+assert(m_version != -1);
}
void
DMASequencer::init()
{
-RubyPort::init();
+MemObject::init();
+assert(m_controller != NULL);
+m_mandatory_q_ptr = m_controller-getMandatoryQueue();
+m_mandatory_q_ptr-setSender(this);
m_is_busy = false;
m_data_block_mask = ~ (~0 RubySystem::getBlockSizeBits());
}
+BaseSlavePort
+DMASequencer::getSlavePort(const std::string if_name, PortID idx)
+{
+// used by the CPUs to connect the caches to the interconnect, and
+// for the x86 case also the interrupt master
+if (if_name != slave) {
+// pass it along to our super class
+return MemObject::getSlavePort(if_name, idx);
+} else {
+return slave_port;
+}
+}
+
+DMASequencer::MemSlavePort::MemSlavePort(const std::string _name,
+DMASequencer *_port, bool _access_phys_mem, PortID id)
+: QueuedSlavePort(_name, _port, queue, id), queue(*_port, *this),
+ access_phys_mem(_access_phys_mem)
+{
+DPRINTF(RubyDma, Created slave memport on ruby sequencer %s\n, _name);
+}
+
+bool
+DMASequencer::MemSlavePort::recvTimingReq(PacketPtr pkt)
+{
+DPRINTF(RubyDma, Timing request for address %#x on port %d\n,
+pkt-getAddr(), id);
+DMASequencer *seq = static_castDMASequencer *(owner);
+
+if (pkt-memInhibitAsserted())
+panic(DMASequencer should never see an inhibited request\n);
+
+assert(isPhysMemAddress(pkt-getAddr()));
+assert(Address(pkt-getAddr()).getOffset() + pkt-getSize() =
+ RubySystem::getBlockSizeBytes());
+
+// Submit the ruby request
+RequestStatus requestStatus = seq-makeRequest(pkt);
+
+// If the request successfully issued then we should return true.
+// Otherwise, we need to tell the port to retry at a later point
+// and return false.
+if (requestStatus == RequestStatus_Issued) {
+DPRINTF(RubyDma, Request %s 0x%x issued\n, pkt-cmdString(),
+pkt-getAddr());
+return true;
+}
+
+// Unless one is using the ruby tester, record the stalled M5 port for
+// later retry when the sequencer becomes free.
+if (!seq-m_usingRubyTester) {
+seq-retry = true;
+}
+
+DPRINTF(RubyDma, Request for address %#x did not issued because %s\n,
+pkt-getAddr(), RequestStatus_to_string(requestStatus));
+
+return false;
+}
+
+void
+DMASequencer::ruby_hit_callback(PacketPtr pkt)
+{
+DPRINTF(RubyDma, Hit callback for %s 0x%x\n, pkt-cmdString(),
+pkt-getAddr());
+
+// The packet was destined for memory and has not yet been turned
+// into a response
+assert(system-isMemAddr(pkt-getAddr()));
+assert(pkt-isRequest());
+slave_port.hitCallback(pkt);
+
+// If we had to stall the slave ports, wake it up because
+// the sequencer likely has free resources now.
+if (retry) {
+retry = false;
+DPRINTF(RubyDma,Sequencer may now be free. SendRetry to port %s\n,
+slave_port.name());
+slave_port.sendRetry();
+}
+
+testDrainComplete();
+}
+
+void
+DMASequencer::testDrainComplete()
+{
+//If we weren't able to drain before, we
[gem5-dev] changeset in gem5: ruby: single physical memory in fs mode
changeset 7a3ad4b09ce4 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=7a3ad4b09ce4 description: ruby: single physical memory in fs mode Both ruby and the system used to maintain memory copies. With the changes carried for programmed io accesses, only one single memory is required for fs simulations. This patch sets the copy of memory that used to reside with the system to null, so that no space is allocated, but address checks can still be carried out. All the memory accesses now source and sink values to the memory maintained by ruby. diffstat: configs/example/fs.py | 15 +++ configs/example/ruby_direct_test.py | 2 +- configs/example/ruby_mem_test.py| 8 +--- configs/example/ruby_network_test.py| 4 +--- configs/example/ruby_random_test.py | 8 +--- configs/example/se.py | 2 +- configs/ruby/MESI_Three_Level.py| 17 - configs/ruby/MESI_Two_Level.py | 23 ++- configs/ruby/MI_example.py | 19 +-- configs/ruby/MOESI_CMP_directory.py | 28 +--- configs/ruby/MOESI_CMP_token.py | 27 +++ configs/ruby/MOESI_hammer.py| 23 +++ configs/ruby/Network_test.py| 2 +- configs/ruby/Ruby.py| 5 +++-- src/mem/protocol/MESI_Two_Level-dma.sm | 5 - src/mem/protocol/MOESI_CMP_directory-dma.sm | 5 - src/mem/protocol/MOESI_CMP_token-dma.sm | 5 - src/mem/ruby/system/DMASequencer.cc | 23 --- src/mem/ruby/system/DMASequencer.hh | 5 + src/mem/ruby/system/Sequencer.py| 5 + tests/configs/memtest-ruby.py | 2 +- tests/configs/pc-simple-timing-ruby.py | 14 +++--- tests/configs/rubytest-ruby.py | 2 +- tests/configs/simple-timing-mp-ruby.py | 2 +- tests/configs/simple-timing-ruby.py | 2 +- 25 files changed, 155 insertions(+), 98 deletions(-) diffs (truncated from 700 to 300 lines): diff -r 30e3715c9405 -r 7a3ad4b09ce4 configs/example/fs.py --- a/configs/example/fs.py Thu Nov 06 00:55:09 2014 -0600 +++ b/configs/example/fs.py Thu Nov 06 05:41:44 2014 -0600 @@ -135,7 +135,10 @@ print sys.stderr, Ruby requires TimingSimpleCPU or O3CPU!! sys.exit(1) -Ruby.create_system(options, test_sys, test_sys.iobus, test_sys._dma_ports) +Ruby.create_system(options, True, test_sys, test_sys.iobus, + test_sys._dma_ports) +test_sys.physmem = [SimpleMemory(range = r, null = True) + for r in test_sys.mem_ranges] # Create a seperate clock domain for Ruby test_sys.ruby.clk_domain = SrcClockDomain(clock = options.ruby_clock, @@ -160,13 +163,9 @@ cpu.interrupts.int_master = test_sys.ruby._cpu_ports[i].slave cpu.interrupts.int_slave = test_sys.ruby._cpu_ports[i].master -test_sys.ruby._cpu_ports[i].access_phys_mem = True - -# Create the appropriate memory controllers -# and connect them to the IO bus -test_sys.mem_ctrls = [TestMemClass(range = r) for r in test_sys.mem_ranges] -for i in xrange(len(test_sys.mem_ctrls)): -test_sys.mem_ctrls[i].port = test_sys.iobus.master +# Connect the ruby io port to the PIO bus, +# assuming that there is just one such port. +test_sys.iobus.master = test_sys.ruby._io_port.slave else: if options.caches or options.l2cache: diff -r 30e3715c9405 -r 7a3ad4b09ce4 configs/example/ruby_direct_test.py --- a/configs/example/ruby_direct_test.py Thu Nov 06 00:55:09 2014 -0600 +++ b/configs/example/ruby_direct_test.py Thu Nov 06 05:41:44 2014 -0600 @@ -109,7 +109,7 @@ options.requests, generator = generator) -Ruby.create_system(options, system) +Ruby.create_system(options, False, system) # Since Ruby runs at an independent frequency, create a seperate clock system.ruby.clk_domain = SrcClockDomain(clock = options.ruby_clock, diff -r 30e3715c9405 -r 7a3ad4b09ce4 configs/example/ruby_mem_test.py --- a/configs/example/ruby_mem_test.py Thu Nov 06 00:55:09 2014 -0600 +++ b/configs/example/ruby_mem_test.py Thu Nov 06 05:41:44 2014 -0600 @@ -128,7 +128,7 @@ dma_ports = [] for (i, dma) in enumerate(dmas): dma_ports.append(dma.test) -Ruby.create_system(options, system, dma_ports = dma_ports) +Ruby.create_system(options, False, system, dma_ports = dma_ports) # Create a top-level voltage domain and clock domain system.voltage_domain = VoltageDomain(voltage = options.sys_voltage) @@
[gem5-dev] changeset in gem5: ruby: provide a backing store
changeset 77787650cbbc in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=77787650cbbc
description:
ruby: provide a backing store
Ruby's functional accesses are not guaranteed to succeed as of now.
While
this is not a problem for the protocols that are currently in the
mainline
repo, it seems that coherence protocols for gpus rely on a backing
store to
supply the correct data. The aim of this patch is to make this backing
store
configurable i.e. it comes into play only when a particular option:
--access-backing-store is invoked.
The backing store has been there since M5 and GEMS were integrated.
The only
difference is that earlier the system used to maintain the backing
store and
ruby's copy was write-only. Sometime last year, we moved to data being
supplied supplied by ruby in SE mode simulations. And now we have
patches on
the reviewboard, which remove ruby's copy of memory altogether and rely
completely on the system's memory to supply data. This patch adds back
a
SimpleMemory member to RubySystem. This member is used only if the
option:
access-backing-store is set to true. By default, the memory would not
be
accessed.
diffstat:
configs/ruby/Ruby.py | 8
src/mem/ruby/system/RubyPort.cc | 35 ++-
src/mem/ruby/system/RubyPort.hh | 7 ++-
src/mem/ruby/system/RubySystem.py | 2 ++
src/mem/ruby/system/Sequencer.py | 3 +--
src/mem/ruby/system/System.cc | 1 +
src/mem/ruby/system/System.hh | 3 +++
7 files changed, 31 insertions(+), 28 deletions(-)
diffs (243 lines):
diff -r fff17530cef6 -r 77787650cbbc configs/ruby/Ruby.py
--- a/configs/ruby/Ruby.py Thu Nov 06 05:42:21 2014 -0600
+++ b/configs/ruby/Ruby.py Thu Nov 06 05:42:21 2014 -0600
@@ -56,6 +56,9 @@
default='2GHz',
help=Clock for blocks running at Ruby system's speed)
+parser.add_option(--access-backing-store, action=store_true,
default=False,
+ help=Should ruby maintain a second copy of memory)
+
# Options related to cache structure
parser.add_option(--ports, action=store, type=int, default=4,
help=used of transitions per cycle which is a proxy \
@@ -229,3 +232,8 @@
ruby._cpu_ports = cpu_sequencers
ruby.num_of_sequencers = len(cpu_sequencers)
ruby.random_seed= options.random_seed
+
+# Create a backing copy of physical memory in case required
+if options.access_backing_store:
+ruby.phys_mem = SimpleMemory(range=AddrRange(options.mem_size),
+ in_addr_map=False)
diff -r fff17530cef6 -r 77787650cbbc src/mem/ruby/system/RubyPort.cc
--- a/src/mem/ruby/system/RubyPort.cc Thu Nov 06 05:42:21 2014 -0600
+++ b/src/mem/ruby/system/RubyPort.cc Thu Nov 06 05:42:21 2014 -0600
@@ -46,6 +46,7 @@
#include mem/protocol/AccessPermission.hh
#include mem/ruby/slicc_interface/AbstractController.hh
#include mem/ruby/system/RubyPort.hh
+#include mem/simple_mem.hh
#include sim/full_system.hh
#include sim/system.hh
@@ -57,16 +58,15 @@
pioSlavePort(csprintf(%s.pio-slave-port, name()), this),
memMasterPort(csprintf(%s.mem-master-port, name()), this),
memSlavePort(csprintf(%s-mem-slave-port, name()), this,
- p-ruby_system, p-access_phys_mem, -1),
- gotAddrRanges(p-port_master_connection_count), drainManager(NULL),
- access_phys_mem(p-access_phys_mem)
+ p-ruby_system, p-access_backing_store, -1),
+ gotAddrRanges(p-port_master_connection_count), drainManager(NULL)
{
assert(m_version != -1);
// create the slave ports based on the number of connected ports
for (size_t i = 0; i p-port_slave_connection_count; ++i) {
slave_ports.push_back(new MemSlavePort(csprintf(%s.slave%d, name(),
-i), this, p-ruby_system, access_phys_mem, i));
+i), this, p-ruby_system, p-access_backing_store, i));
}
// create the master ports based on the number of connected ports
@@ -155,9 +155,10 @@
}
RubyPort::MemSlavePort::MemSlavePort(const std::string _name, RubyPort *_port,
- RubySystem *_system, bool _access_phys_mem, PortID id)
+ RubySystem *_system,
+ bool _access_backing_store, PortID id)
: QueuedSlavePort(_name, _port, queue, id), queue(*_port, *this),
- ruby_system(_system), access_phys_mem(_access_phys_mem)
+ ruby_system(_system), access_backing_store(_access_backing_store)
{
DPRINTF(RubyPort, Created slave memport on ruby sequencer %s\n, _name);
}
@@ -281,11 +282,11 @@
RubyPort::MemSlavePort::recvFunctional(PacketPtr pkt)
{
DPRINTF(RubyPort, Functional access for address: %#x\n, pkt-getAddr());
-RubyPort
[gem5-dev] changeset in gem5: ruby: interface with classic memory controller
changeset fff17530cef6 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=fff17530cef6 description: ruby: interface with classic memory controller This patch is the final in the series. The whole series and this patch in particular were written with the aim of interfacing ruby's directory controller with the memory controller in the classic memory system. This is being done since ruby's memory controller has not being kept up to date with the changes going on in DRAMs. Classic's memory controller is more up to date and supports multiple different types of DRAM. This also brings classic and ruby ever more close. The patch also changes ruby's memory controller to expose the same interface. diffstat: configs/common/MemConfig.py|3 +- configs/example/fs.py |2 - configs/example/ruby_direct_test.py| 20 +- configs/example/ruby_mem_test.py |1 - configs/example/ruby_random_test.py|3 +- configs/example/se.py |5 - configs/ruby/MESI_Three_Level.py | 14 +- configs/ruby/MESI_Two_Level.py | 17 +- configs/ruby/MI_example.py | 20 +- configs/ruby/MOESI_CMP_directory.py| 16 +- configs/ruby/MOESI_CMP_token.py| 16 +- configs/ruby/MOESI_hammer.py | 21 +- configs/ruby/Ruby.py | 88 --- src/mem/protocol/MESI_Two_Level-dir.sm | 81 +- src/mem/protocol/MI_example-dir.sm | 76 + src/mem/protocol/MOESI_CMP_directory-dir.sm| 85 +- src/mem/protocol/MOESI_CMP_token-dir.sm| 90 ++- src/mem/protocol/MOESI_hammer-dir.sm | 106 +++-- src/mem/protocol/RubySlicc_Defines.sm | 16 + src/mem/protocol/RubySlicc_Types.sm|6 - src/mem/ruby/SConscript|1 - src/mem/ruby/network/MessageBuffer.cc |6 +- src/mem/ruby/slicc_interface/AbstractController.cc | 164 +- src/mem/ruby/slicc_interface/AbstractController.hh | 65 +- src/mem/ruby/slicc_interface/Controller.py |8 +- src/mem/ruby/structures/Cache.py |1 - src/mem/ruby/structures/DirectoryMemory.py |2 - src/mem/ruby/structures/MemoryControl.cc | 49 src/mem/ruby/structures/MemoryControl.hh | 114 -- src/mem/ruby/structures/MemoryControl.py | 39 --- src/mem/ruby/structures/MemoryNode.cc |2 +- src/mem/ruby/structures/MemoryNode.hh | 12 +- src/mem/ruby/structures/MemoryVector.hh| 237 - src/mem/ruby/structures/RubyMemoryControl.cc | 182 +++ src/mem/ruby/structures/RubyMemoryControl.hh | 62 - src/mem/ruby/structures/RubyMemoryControl.py | 10 +- src/mem/ruby/structures/SConscript |2 - src/mem/ruby/system/RubySystem.py |4 +- src/mem/ruby/system/Sequencer.py |2 +- src/mem/ruby/system/System.cc | 58 + src/mem/ruby/system/System.hh | 14 - src/mem/slicc/symbols/StateMachine.py |6 +- src/python/swig/pyobject.cc|2 +- tests/configs/memtest-ruby.py |1 - tests/configs/pc-simple-timing-ruby.py |3 - tests/configs/rubytest-ruby.py |2 +- tests/configs/simple-timing-mp-ruby.py |3 +- tests/configs/simple-timing-ruby.py|4 +- 48 files changed, 600 insertions(+), 1141 deletions(-) diffs (truncated from 3031 to 300 lines): diff -r 5777a3e55603 -r fff17530cef6 configs/common/MemConfig.py --- a/configs/common/MemConfig.py Thu Nov 06 05:42:20 2014 -0600 +++ b/configs/common/MemConfig.py Thu Nov 06 05:42:21 2014 -0600 @@ -54,7 +54,8 @@ (lpddr2_s4_1066_x32, LPDDR2_S4_1066_x32), (lpddr3_1600_x32, LPDDR3_1600_x32), (wio_200_x128, WideIO_200_x128), -(dramsim2, DRAMSim2) +(dramsim2, DRAMSim2), +(ruby_memory, RubyMemoryControl) ] # Filtered list of aliases. Only aliases for existing memory diff -r 5777a3e55603 -r fff17530cef6 configs/example/fs.py --- a/configs/example/fs.py Thu Nov 06 05:42:20 2014 -0600 +++ b/configs/example/fs.py Thu Nov 06 05:42:21 2014 -0600 @@ -137,8 +137,6 @@ Ruby.create_system(options, True, test_sys, test_sys.iobus, test_sys._dma_ports) -test_sys.physmem = [SimpleMemory(range = r, null = True) - for r in test_sys.mem_ranges] # Create a seperate clock domain for Ruby
[gem5-dev] changeset in gem5: ruby: slicc: allow adding a bool to an int, l...
changeset ca248520649f in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=ca248520649f
description:
ruby: slicc: allow adding a bool to an int, like C++.
diffstat:
src/mem/slicc/ast/OperatorExprAST.py | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diffs (12 lines):
diff -r 7740e0d97d48 -r ca248520649f src/mem/slicc/ast/OperatorExprAST.py
--- a/src/mem/slicc/ast/OperatorExprAST.py Thu Nov 06 05:42:20 2014 -0600
+++ b/src/mem/slicc/ast/OperatorExprAST.py Thu Nov 06 05:42:20 2014 -0600
@@ -69,6 +69,8 @@
(Cycles, Cycles, Cycles),
(Cycles, int, Cycles),
(Scalar, int, Scalar),
+ (int, bool, int),
+ (bool, int, int),
(int, Cycles, Cycles)]
else:
self.error(No operator matched with {0}! .format(self.op))
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: ruby: coherence protocols: remove data block ...
changeset 13312d6e1caf in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=13312d6e1caf
description:
ruby: coherence protocols: remove data block from dirctory entry
This patch removes the data block present in the directory entry
structure
of each protocol in gem5's mainline. Firstly, this is required for
moving
towards common set of memory controllers for classic and ruby memory
systems.
Secondly, the data block was being misused in several places. It was
being
used for having free access to the physical memory instead of calling
on the
memory controller.
From now on, the directory controller will not have a direct visibility
into
the physical memory. The Memory Vector object now resides in the
Memory Controller class. This also means that some significant changes
are
being made to the functional accesses in ruby.
diffstat:
src/mem/protocol/MESI_Three_Level-L0cache.sm | 21 ++-
src/mem/protocol/MESI_Three_Level-L1cache.sm | 21 ++-
src/mem/protocol/MESI_Two_Level-L1cache.sm | 21 ++-
src/mem/protocol/MESI_Two_Level-L2cache.sm | 21 ++-
src/mem/protocol/MESI_Two_Level-dir.sm | 52 ++--
src/mem/protocol/MESI_Two_Level-dma.sm | 11 +-
src/mem/protocol/MI_example-cache.sm | 21 ++-
src/mem/protocol/MI_example-dir.sm | 65 +++---
src/mem/protocol/MI_example-dma.sm |8 +-
src/mem/protocol/MOESI_CMP_directory-L1cache.sm| 30 +++-
src/mem/protocol/MOESI_CMP_directory-L2cache.sm| 23 +++-
src/mem/protocol/MOESI_CMP_directory-dir.sm| 97 --
src/mem/protocol/MOESI_CMP_directory-dma.sm|8 +-
src/mem/protocol/MOESI_CMP_token-L1cache.sm| 11 +-
src/mem/protocol/MOESI_CMP_token-L2cache.sm| 11 +-
src/mem/protocol/MOESI_CMP_token-dir.sm| 96 ++-
src/mem/protocol/MOESI_CMP_token-dma.sm|8 +-
src/mem/protocol/MOESI_hammer-cache.sm | 30 +++-
src/mem/protocol/MOESI_hammer-dir.sm | 128
src/mem/protocol/MOESI_hammer-dma.sm |8 +-
src/mem/protocol/Network_test-cache.sm |8 +-
src/mem/protocol/Network_test-dir.sm |8 +-
src/mem/protocol/RubySlicc_Types.sm|2 +
src/mem/ruby/slicc_interface/AbstractCacheEntry.hh |7 +
src/mem/ruby/slicc_interface/AbstractController.hh |3 +-
src/mem/ruby/slicc_interface/AbstractEntry.hh |6 -
src/mem/ruby/structures/DirectoryMemory.cc |2 -
src/mem/ruby/structures/DirectoryMemory.hh |3 -
src/mem/ruby/structures/MemoryControl.hh |4 +-
src/mem/ruby/structures/RubyMemoryControl.cc | 27 +++-
src/mem/ruby/structures/RubyMemoryControl.hh | 12 +-
src/mem/ruby/system/System.cc | 45 +--
32 files changed, 417 insertions(+), 401 deletions(-)
diffs (truncated from 1979 to 300 lines):
diff -r ca248520649f -r 13312d6e1caf
src/mem/protocol/MESI_Three_Level-L0cache.sm
--- a/src/mem/protocol/MESI_Three_Level-L0cache.sm Thu Nov 06 05:42:20
2014 -0600
+++ b/src/mem/protocol/MESI_Three_Level-L0cache.sm Thu Nov 06 05:42:20
2014 -0600
@@ -205,13 +205,28 @@
return AccessPermission:NotPresent;
}
- DataBlock getDataBlock(Address addr), return_by_ref=yes {
+ void functionalRead(Address addr, Packet *pkt) {
TBE tbe := TBEs[addr];
if(is_valid(tbe)) {
-return tbe.DataBlk;
+ testAndRead(addr, tbe.DataBlk, pkt);
+} else {
+ testAndRead(addr, getCacheEntry(addr).DataBlk, pkt);
+}
+ }
+
+ int functionalWrite(Address addr, Packet *pkt) {
+int num_functional_writes := 0;
+
+TBE tbe := TBEs[addr];
+if(is_valid(tbe)) {
+ num_functional_writes := num_functional_writes +
+testAndWrite(addr, tbe.DataBlk, pkt);
+ return num_functional_writes;
}
-return getCacheEntry(addr).DataBlk;
+num_functional_writes := num_functional_writes +
+testAndWrite(addr, getCacheEntry(addr).DataBlk, pkt);
+return num_functional_writes;
}
void setAccessPermission(Entry cache_entry, Address addr, State state) {
diff -r ca248520649f -r 13312d6e1caf
src/mem/protocol/MESI_Three_Level-L1cache.sm
--- a/src/mem/protocol/MESI_Three_Level-L1cache.sm Thu Nov 06 05:42:20
2014 -0600
+++ b/src/mem/protocol/MESI_Three_Level-L1cache.sm Thu Nov 06 05:42:20
2014 -0600
@@ -205,13 +205,28 @@
return AccessPermission:NotPresent;
}
- DataBlock getDataBlock(Address addr), return_by_ref=yes {
+ void functionalRead(Address addr, Packet *pkt) {
TBE tbe := TBEs[addr];
if(is_valid(tbe)) {
-return tbe.DataBlk;
+ testAndRead(addr, tbe.DataBlk, pkt);
+} else {
+ testAndRead(addr, getCacheEntry(addr).DataBlk, pkt);
+}
+ }
+
+ int
Re: [gem5-dev] Review Request 2469: mem: dram ctrl: correct errors due to busBusyUntil variable
On Thu, 6 Nov 2014, Andreas Hansson wrote: On Oct. 31, 2014, 10:21 p.m., Nilay Vaish wrote: Andreas, please review this patch. I would like the ruby-related patches be committed soon as possible. I'm surprised this is needed. The busBusyUntil should be initialised to a sufficiently high value that this would never occur. Could you elaborate on when the problem arises (under what conditions)? I encountered problems when simulating with ruby and dram ctrl and starting from a checkpoint. Ruby issues memory requests in its startup() function when loading a checkpoint. It seems that the startup() was not called on the dram ctrl when ruby started issuing requests. This means that busBusyUntil was at 0 to begin with. Since busBusyUntil is unsigned, subtracting a higher value from it results in a very large tick value. This results in a dead lock. I added the checks as shown in the patch to avoid subtracting a larger number from a smaller number. This resolved the problem. As of now I am unsure if this is right way to solve the problem. Is it possible to move the initialization of busBusyUntil to init() and unserialize()? What's the earliest stage in a sim object initialization phase that can call curTick()? -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2469: mem: dram ctrl: correct errors due to busBusyUntil variable
We want to keep the checkpoint state for caches independent of the protocol being used. To reconstruct the state of caches, therefore, we replay memory accesses to the addresses present in the checkpoint. This can only be done after every component is in a state where they are ready to begin simulation. Earlier we could ensure this within ruby. But now that we are using dram ctrl, we would need a new stage. -- Nilay On Thu, 6 Nov 2014, Andreas Hansson wrote: Hi Nilay, Apologies for my limited insight in how Ruby restores from a checkpoint, but could we not avoid injecting any packets all together? Is there a fundamental reason why this is needed? Could we not let the various objects be responsible for their own portion of the checkpoint state? Andreas On 06/11/2014 16:32, Nilay Vaish ni...@cs.wisc.edu wrote: Ok, in that case, I would add one more stage to the initialization phase so as to allow ruby to restore from a checkpoint. -- Nilay On Thu, 6 Nov 2014, Andreas Hansson wrote: Hi Nilay, I see. The reason that it is set in startup is due to the checkpoints. I would argue that we should not allow any transactions to be issued in startup. Would that work? Andreas On 06/11/2014 15:55, Nilay Vaish ni...@cs.wisc.edu wrote: On Thu, 6 Nov 2014, Andreas Hansson wrote: On Oct. 31, 2014, 10:21 p.m., Nilay Vaish wrote: Andreas, please review this patch. I would like the ruby-related patches be committed soon as possible. I'm surprised this is needed. The busBusyUntil should be initialised to a sufficiently high value that this would never occur. Could you elaborate on when the problem arises (under what conditions)? I encountered problems when simulating with ruby and dram ctrl and starting from a checkpoint. Ruby issues memory requests in its startup() function when loading a checkpoint. It seems that the startup() was not called on the dram ctrl when ruby started issuing requests. This means that busBusyUntil was at 0 to begin with. Since busBusyUntil is unsigned, subtracting a higher value from it results in a very large tick value. This results in a dead lock. I added the checks as shown in the patch to avoid subtracting a larger number from a smaller number. This resolved the problem. As of now I am unsure if this is right way to solve the problem. Is it possible to move the initialization of busBusyUntil to init() and unserialize()? What's the earliest stage in a sim object initialization phase that can call curTick()? -- Nilay -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2469: mem: dram ctrl: correct errors due to busBusyUntil variable
On Thu, 6 Nov 2014, Andreas Hansson wrote: Hi Nilay, I would really not like us to introduce yet another step in the initialisation process unless it is absolutely necessary. The steps done in the DRAM controller relies on curTick being set correctly, and to the best of my knowledge the first opportunity to do this is startup. I would prefer to stick to the rule that only functional transactions are allowed up till this point. We will not be able to load the checkpointed state only with functional reads and writes since functional accesses do not update coherence states in ruby controllers. But it seems we can limit timing accesses to the ruby portion and perform functional accesses to the dram. This should allow use to keep the dram ctrl same as it is now. I think the best solution would be if Ruby would load its state in loadState/unserialize without using timing transactions, but I do not have a good suggestion for how to make this happen. Additionally, how do we even know what transactions to play back when it is done in startup today? We just issue read for all the addresses that are part of the checkpointed cache state. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2466: ruby: provide a second copy of the memory
On Sun, 26 Oct 2014, Steve Reinhardt wrote: On Sun, Oct 26, 2014 at 2:23 PM, Nilay Vaish ni...@cs.wisc.edu wrote: Marc Orr asked me the same question last year. I am pasting the examples I gave him: a. the data in the message is stale, but the sender does not know about it. Take a look at the MESI CMP directory protocol. In the case when an L1 controller (A) sends a PUTX to the L2 controller, it is possible that the L2 controller has already transferred the ownership to some L1 controller (B). In this case, it is possible that there are two message buffers that contain messages from A and B to the L2 controller, but it is message from B which has the 'right' data. Interesting. I can see how this technically could be a problem, but it seems like a pretty unlikely corner case. Have you seen it happen in practice, and if so, what was the functional read for? I suppose I just have a hard time imagining an actual program that has a lot of contention on a block that ends up being used as a parameter to a system call. I guess it could happen with a syscall that's specifically for synchronization, like futex. About an year, I had actually committed a patch that returned the first data value it found (after making sure that no controller had the block in a stable state). I ran into the case illustrated above and I had to rollback the patch. b. no data is present in the message and the receiver will infer that the data it has is correct since the message did not have any data. This seems like it should pretty easy to fix... if you're querying the message to see if it has relevant data, then if the address matches but there is no data, you should just return false. I'd think there'd be a protocol-independent way to determine that a message has no data. It's similar to the idea that you have to check the valid bit in the cache, you can't just look for a tag match. I doubt we can do this in protocol independent way. I think the presence / absence of data is decided by the type of the message which is a protocol specific enum. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2466: ruby: provide a second copy of the memory
On Mon, 27 Oct 2014, Steve Reinhardt wrote: On Mon, Oct 27, 2014 at 6:58 AM, Nilay Vaish ni...@cs.wisc.edu wrote: On Sun, 26 Oct 2014, Steve Reinhardt wrote: On Sun, Oct 26, 2014 at 2:23 PM, Nilay Vaish ni...@cs.wisc.edu wrote: Marc Orr asked me the same question last year. I am pasting the examples I gave him: a. the data in the message is stale, but the sender does not know about it. Take a look at the MESI CMP directory protocol. In the case when an L1 controller (A) sends a PUTX to the L2 controller, it is possible that the L2 controller has already transferred the ownership to some L1 controller (B). In this case, it is possible that there are two message buffers that contain messages from A and B to the L2 controller, but it is message from B which has the 'right' data. Interesting. I can see how this technically could be a problem, but it seems like a pretty unlikely corner case. Have you seen it happen in practice, and if so, what was the functional read for? I suppose I just have a hard time imagining an actual program that has a lot of contention on a block that ends up being used as a parameter to a system call. I guess it could happen with a syscall that's specifically for synchronization, like futex. About an year, I had actually committed a patch that returned the first data value it found (after making sure that no controller had the block in a stable state). I ran into the case illustrated above and I had to rollback the patch. Do you recall any details of how you ran into this? Was this in the process of executing an emulated syscall? How did you detect the problem? Nope. It might have been that I was running a tester, might have been that I was running an actual application. I probably first figured which was commit was causing the error and then used the trace of the events in the protocol to figure out the actual problem. b. no data is present in the message and the receiver will infer that the data it has is correct since the message did not have any data. This seems like it should pretty easy to fix... if you're querying the message to see if it has relevant data, then if the address matches but there is no data, you should just return false. I'd think there'd be a protocol-independent way to determine that a message has no data. It's similar to the idea that you have to check the valid bit in the cache, you can't just look for a tag match. I doubt we can do this in protocol independent way. I think the presence / absence of data is decided by the type of the message which is a protocol specific enum. I don't see how this is any harder than having the cache controller know whether a block is valid or writable in a protocol-independent fashion. Unless the entire message format is completely protocol defined, I'd think it would be even easier, since you could directly check whether there's a data or payload section in the message. The message format, the data block associated with a cached address, the dirty bit associated with block: all these are defined by the protocol. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2466: ruby: provide a second copy of the memory
On Mon, 27 Oct 2014, Beckmann, Brad wrote: I agree with Joel that this has been an interesting discussion. While there are questions about how these situations can occur and what is the best way to fix them, there doesn't seem to be anyone resisting the fact that this patch should be checked in, correct? I think it is very important that we not require protocols to always provide completely functional memory. I still need to look into how checkpoints will work. With the current code, the existing checkpoints will not work at all. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
