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. 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 RSP: 0018:ffff88001f87de38 EFLAGS: 0000026c RAX: ffffffff80629f01 RBX: ffffffff807a8020 RCX: ffff880001006480 RDX: 0000000000000000 RSI: ffff88001f8a5180 RDI: ffffffff807a8020 RBP: ffff88001f87de68 R08: ffff88001f87c000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88001f8a5180 R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88001f84bec0(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000 Process swapper (pid: 0, threadinfo ffff88001f87c000, task ffff88001f86e620) 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 ]------------ ---[ end trace 4eaa2a86a8e2da22 ]--- Kernel panic - not syncing: Attempted to kill the idle task! kernel BUG at kernel/fork.c:449! invalid opcode: 0000 [#2] SMP last sysfs file: CPU 0 Modules linked in: Pid: 0, comm: swapper Tainted: G D W 2.6.28-rc4-dirty #5 RIP: 0010:[<ffffffff80238bbe>] [<ffffffff80238bbe>] __mmdrop+0x2e/0x40 RSP: 0018:ffffffff808c3e78 EFLAGS: 0000026c RAX: ffffffff80629f01 RBX: ffffffff807a8020 RCX: ffff880001006480 RDX: 0000000000000000 RSI: ffff88001f9f07e0 RDI: ffffffff807a8020 RBP: ffffffff808c3ea8 R08: ffffffff808c2000 R09: ffff88001f99b7f0 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88001f9f07e0 R13: 0000000000000040 R14: 0000000000000000 R15: ffff88001f9f9ed0 FS: 0000000000000000(0000) GS:ffffffff808bd980(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000 Process swapper (pid: 0, threadinfo ffffffff808c2000, task ffffffff807a8340) Stack: ffffffff807a8020 ffffffff80237a4c ffffffff807a8340 ffffffff8091ed80 ffffffff807a8020 ffffffff80629f40 ffffffff808c3f78 ffffffff806154f4 0000000000000000 0000000000000000 0000000000000000 ffffffff808c3f18 Call Trace: [<ffffffff80237a4c>] ? finish_task_switch+0x9c/0xa0 [<ffffffff806154f4>] thread_return+0x3d/0x609 [<ffffffff8020a97d>] cpu_idle+0x8d/0xa0 [<ffffffff808cdc19>] ? start_kernel+0x316/0x321 [<ffffffff808cd405>] ? x86_64_start_kernel+0xd9/0xdd 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 <ffffffff808c3e78> Thanks, Thom Popovici On Sat, Nov 22, 2014 at 2:52 PM, Steve Reinhardt <ste...@gmail.com> wrote: > I'm not questioning your motivations, just pointing out why we never > bothered to fix the problem even though we were aware of it :). > > Steve > > On Sat, Nov 22, 2014 at 11:39 AM, Thom Popovici <dorupopovic...@gmail.com> > wrote: > >> I agree with the fact that it is unrealistic not having caches and >> separated ones, however for what I want to experiment I do not want to have >> caches :). I can make the data cache and the instruction cache 64 B each >> (the size equal with the size of a line) and hope for the best. >> >> I did not use that flag. I will try it in a couple of minutes. >> >> Thanks for the information >> >> On Sat, Nov 22, 2014 at 2:20 PM, Mitch Hayenga < >> mitch.hayenga+g...@gmail.com> wrote: >> >>> Have you tried running with the O3CPUAll debug flag? That may shed some >>> more light on whats happening. Steve's suggestion sounds like a >>> possibility. >>> >>> On Sat, Nov 22, 2014 at 12:24 PM, Steve Reinhardt via gem5-users < >>> gem5-users@gem5.org> wrote: >>> >>>> I don't recall the details, but there's some issue with data accesses >>>> and instruction fetches sharing the same port to memory with O3 that leads >>>> to a livelock (or deadlock?) situation... something like you need to do an >>>> ifetch to make forward progress, but every time the port is free you >>>> re-issue a speculative data access instead, or maybe it's the other way >>>> around. We have run into this before--I think the same problem occurs with >>>> a unified L1--but since it goes away once you use split caches, and it's >>>> unrealistic not to have split caches anyway, we never considered it worth >>>> fixing. >>>> >>>> Steve >>>> >>>> >>>> On Sat, Nov 22, 2014 at 9:27 AM, Thom Popovici via gem5-users < >>>> gem5-users@gem5.org> wrote: >>>> >>>>> Hi, all! >>>>> >>>>> I want to remove the caches from the full system configuration. I want >>>>> multiple processors that are directly connected to the membus and the >>>>> memory. As far as I saw the O3CPU demands caches, why? I managed to >>>>> modify >>>>> the function request_caches from True to False. I managed to >>>>> instantiate >>>>> all the objects without errors but Gem5 freezes up at the very >>>>> beginning: >>>>> >>>>> Entering event queue @ 0. Starting simulation... >>>>> >>>>> Any ideas. >>>>> >>>>> Thanks so much >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >> >> >> -- >> Thom Popovici >> > > -- Thom Popovici
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
