[gem5-users] PMU in GEM5
Hello everyone, Is it possible to use the PMU with Arm ISA? ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] Dynamically change options of BasicLink / BaseGarnetNetwork class
Hello, I would like to be able to change the *bandwidth_factor* and *ni_flit_size* variables dynamically without the need to rebuild gem5 executable. The variables are found in BasicLink.py and BaseGarnetNetwork.py. ( ruby network and garnet ) I have cheched Options.py, Ruby.py and network_test.py and have managed to add new options for classes like the NetworkTester (networktest.cc.) However I 'm still searching for the aforementioned cases. Could anyone help me with it? Thanks in advance! ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] stack smashing detected when built x86 full system
Hi, I’m currently trying to build full system under x86 in order to run splash2 benchmarks with multi-cpus processor. Here’s my system environment: 32-bit ubuntu linux system under VM on OS X. To achieve my cache requirements, I built X86_MOESI_hammer in order to have private l2caches. Here are my steps to build full system so far: 1. Downloaded x86-system and config-x86 packages and extracted them. Moved them to dictionary ~/gem5. 2. Downloaded ALPHA full system files and copied linux-bigswap2.img to ~/gem5/x86-system/disks/. 3. Modified path in /configs/common/SysPath.py to path = [ '/dist/m5/system', '~/gem5/x86-system’ ]”. 4. Changed name of ~/gem5/x86-system/disks/linux-x86.img to x86root.img. Then I typed following command build/X86_MOESI_hammer/gem5.opt -d m5out configs/example/fs.py —kernel=x86_64-vmlinux-2.6.22.9”. I didn’t get error but the program terminated due to “stack smashing detected”. Here’s what I got after typing the commands above: gem5 Simulator System. http://gem5.org http://gem5.org/ gem5 is copyrighted software; use the --copyright option for details. gem5 compiled Apr 20 2015 18:12:20 gem5 started Apr 21 2015 16:17:51 gem5 executing on ubuntu command line: build/X86_MOESI_hammer/gem5.opt -d m5out configs/example/fs.py --kernel=x86_64-vmlinux-2.6.22.9 Global frequency set at 1 ticks per second warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (512 Mbytes) info: kernel located at: /home/hancle/gem5/x86-system/binaries/x86_64-vmlinux-2.6.22.9 Listening for com_1 connection on port 3456 0: rtc: Real-time clock set to Sun Jan 1 00:00:00 2012 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 warn: Reading current count from inactive timer. REAL SIMULATION info: Entering event queue @ 0. Starting simulation… warn: Don't know what interrupt to clear for console. *** stack smashing detected ***: build/X86_MOESI_hammer/gem5.opt terminated Program aborted at cycle 7027708000 Aborted (core dumped) I couldn’t find any idea in previous postings, if anyone knows where the problem is please let know. Thanks Hancle ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] bytesWritten (8 * number of 64-bit stores to unique addresses)
Hello Patrick, Can you check the number of last level cache misses as reported by stats.text? Prathap On Apr 21, 2015 5:47 PM, Patrick plafr...@gmail.com wrote: I looked back at this, and I'm still not sure it's clear to me what is going on. I decreased the size of the write queue to 2, and when running the simulation described in my previous message (in which 512 64-bit stores to unique addresses are issued), bytesWritten in one run was reported to be only 1,664 bytes. With the write queue set to size 2, I would expect bytesWritten to be at least 4096 - 128 = 3,968 bytes (the burstSize is 64 bytes). Any additional help is appreciated. Regards, Patrick On Thu, Apr 16, 2015 at 2:07 PM, Patrick plafr...@gmail.com wrote: Thanks, Andreas. This makes sense. On Wed, Apr 15, 2015 at 5:26 PM, Andreas Hansson andreas.hans...@arm.com wrote: Hi Patrick, When it comes to the stores you are looking at a rather small number of operations, and my guess is that they are still in the DRAM write queues. These queues are not drained at the moment once the writes fall below the “low water mark”. Andreas From: Patrick plafr...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.org Date: Wednesday, 15 April 2015 19:13 To: gem5 users mailing list gem5-users@gem5.org Subject: [gem5-users] bytesWritten (8 * number of 64-bit stores to unique addresses) I am looking at stats.txt for the amount of data written to the DRAM during the execution of a process in full system mode. I looked at the execution trace, and there are at least 512 64-bit stores to unique addresses. However, stats.txt reports only 2,304 bytesWritten to the memory. It is a 4-channel memory configuration. stats.txt reports 1,152 bytesWritten on channel 0, 0 bytesWritten to channel 1, 0 bytesWritten to channel 2, and 1,152 bytesWritten to channel 3. Does anyone know what would cause this? I thought maybe the data might be getting left in the caches, but I am waiting until the process exits before calling m5 resetstats. The bytesReadDRAM is less than expected, also, based on the number of loads in the instruction trace. I thought perhaps this was because no-write allocate was being used, but the discussion linked below suggests that default is to use write-allocate. I can't find where this is configured in gem5, so I'm not able to check this at the moment. http://comments.gmane.org/gmane.comp.emulators.m5.users/12597 Any help is appreciated. - Patrick -- 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-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] bytesWritten (8 * number of 64-bit stores to unique addresses)
I looked back at this, and I'm still not sure it's clear to me what is going on. I decreased the size of the write queue to 2, and when running the simulation described in my previous message (in which 512 64-bit stores to unique addresses are issued), bytesWritten in one run was reported to be only 1,664 bytes. With the write queue set to size 2, I would expect bytesWritten to be at least 4096 - 128 = 3,968 bytes (the burstSize is 64 bytes). Any additional help is appreciated. Regards, Patrick On Thu, Apr 16, 2015 at 2:07 PM, Patrick plafr...@gmail.com wrote: Thanks, Andreas. This makes sense. On Wed, Apr 15, 2015 at 5:26 PM, Andreas Hansson andreas.hans...@arm.com wrote: Hi Patrick, When it comes to the stores you are looking at a rather small number of operations, and my guess is that they are still in the DRAM write queues. These queues are not drained at the moment once the writes fall below the “low water mark”. Andreas From: Patrick plafr...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.org Date: Wednesday, 15 April 2015 19:13 To: gem5 users mailing list gem5-users@gem5.org Subject: [gem5-users] bytesWritten (8 * number of 64-bit stores to unique addresses) I am looking at stats.txt for the amount of data written to the DRAM during the execution of a process in full system mode. I looked at the execution trace, and there are at least 512 64-bit stores to unique addresses. However, stats.txt reports only 2,304 bytesWritten to the memory. It is a 4-channel memory configuration. stats.txt reports 1,152 bytesWritten on channel 0, 0 bytesWritten to channel 1, 0 bytesWritten to channel 2, and 1,152 bytesWritten to channel 3. Does anyone know what would cause this? I thought maybe the data might be getting left in the caches, but I am waiting until the process exits before calling m5 resetstats. The bytesReadDRAM is less than expected, also, based on the number of loads in the instruction trace. I thought perhaps this was because no-write allocate was being used, but the discussion linked below suggests that default is to use write-allocate. I can't find where this is configured in gem5, so I'm not able to check this at the moment. http://comments.gmane.org/gmane.comp.emulators.m5.users/12597 Any help is appreciated. - Patrick -- 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-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
