On Monday 24 November 2014 01:46:53 Thom Popovici via gem5-users wrote: > Hello again. > > So I have tried making the caches as small as possible, therefore trying to > remove the contention at the cache level. The command line that i hit was: > ./build/X86/gem5.opt -d ./test1 ./configs/example/fs.py -n 2 > --cpu-type=detailed --caches --l1d_size=128B --l1i_size=128B --l1d_assoc=1 > --l1i_assoc=1 --cacheline_size=64 --mem-type=ddr3_1600_x64 > --script=./runbs2.rcS (where runbs2.rcS runs blackscholes algorithm). > So the simulator started nicely. The execution started till a certain point > when it froze. I tried m5term into it, nothing. I end up with this: > PARSEC Benchmark Suite Version 2.1 > [HOOKS] PARSEC Hooks Version 1.2 > Num of Options: 16384 > Num of Runs: 100 > Size o[tpopovici@thompopovici test1]$ > > It has been 24 hours and no change.
Well.. without caches you really slow-down execution of any benchmark a lot. Imagine that every instruction fetch / data access now needs to access memory. So instead of say four cycles access latency for these you get something on the order of 200 clock cycles. This means that you expect a slowdown of ~50x, meaning a benchmark that originally took a minute to run now takes an hour. While gem5's event-based model will soften the blow somewhat, you still need to simulate more cycles and that can slow down your simulation. I suggest you look into the execution trace with the debug flag suggested earlier to see what the pipeline is doing and whether things are stuck or just *very* slow. > I also tried the full system simulation with the defaults cache sizes: > ./build/X86/gem5.opt -d ./test1 ./configs/example/fs.py -n 2 > --cpu-type=detailed --caches --mem-type=ddr3_1600_x64 --script=./runbs2.rcS > (where runbs2.rcS runs blackscholes algorithm). > The simulator does not even start it dies at: > > PCI: Using configuration type 1 for base access > ------------[ cut here ]------------ > kernel BUG at kernel/fork.c:449! > invalid opcode: 0000 [#1] SMP > last sysfs file: > CPU 1 > Modules linked in: > Pid: 0, comm: swapper Tainted: G W 2.6.28-rc4-dirty #5 > RIP: 0010:[<ffffffff80238bbe>] [<ffffffff80238bbe>] __mmdrop+0x2e/0x40 > Stack: > ffffffff807a8020 ffffffff80237a4c ffff88001f86e620 ffffffff8091ed80 > ffffffff807a8020 ffffffff80629f40 ffff88001f87df38 ffffffff806154f4 > 0000000000000000 0000000000000074 0000000000000002 ffff88001f87ded8 > Call Trace: > [<ffffffff80237a4c>] ? finish_task_switch+0x9c/0xa0 > [<ffffffff806154f4>] thread_return+0x3d/0x609 > [<ffffffff802592d0>] ? clockevents_set_mode+0x20/0x40 > [<ffffffff8020a97d>] cpu_idle+0x8d/0xa0 > Code: 20 80 7a 80 53 48 89 fb 74 21 48 8b 77 48 e8 3a 0c ff ff 48 89 df e8 > 32 61 fd ff 48 89 de 48 8b 3d 90 15 71 00 5b e9 82 bc 05 00 <0f> 0b eb fe > 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 53 48 89 > RIP [<ffffffff80238bbe>] __mmdrop+0x2e/0x40 > RSP <ffff88001f87de38> > ------------[ cut here ]------------ Might be worth throwing these instruction bytes into a disassembler and check what went wrong, here. This looks like a genuine & different issue, but I will leave that to the x86 devs, here ;) -- Hope that helps, Stephan Stephan Diestelhorst Staff Engineer ARM R&D Systems -- 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
