Re: [gem5-users] Simulation does not stop, SE mode, 2 cpus, DerivO3CPU, ruby memory
Hi, A ticket is already opened about this at Jira https://gem5.atlassian.net/projects/GEM5/issues Arun: This repo (https://gem5.googlesource.com/amd/gem5/) will solve your problem On Tue, Feb 18, 2020 at 1:06 PM Ciro Santilli wrote: > Hi Arun, > > "I started using ruby memory model after reading from gem5 email > archive that classic memory does not work with multicore DerivO3CPU.": > I didn't know this, where was this mentioned? I have just run an ARM > pthread hello world on DerivO3CPU 2 cores and it worked on master. > > I reproduce your problem on X86 DerivO3CPU classic but not ARM > DerivO3CPU. But a pthread hello world (single binary under --cmd that > spanws threads) with 2 CPUs worked, I don't know the cause. If no one > knows about this issue, you need to try and debug it :-) > > I would also open a ticket for this bug at > https://gem5.atlassian.net/browse/GEM5 and move all discussion there. > > > > > On Tue, Feb 18, 2020 at 4:43 AM Arun Kavumkal > wrote: > > > > Hi, > > I am trying to run gem5 in SE mode with number of cpus 2, cpu type > DerivO3CPU, and ruby memory model using following command, but the > simulation does not stop even after results are produced , ie "Hello > world!" is printed to stdout > > > > build/X86_MESI_Three_Level/gem5.opt configs/example/se.py -n 2 --ruby > --cpu-type=DerivO3CPU -c > 'tests/test-progs/hello/bin/x86/linux/hello;tests/test-progs/hello/bin/x86/linux/hello' > > > > I started using ruby memory model after reading from gem5 email archive > that classic memory does not work with multicore DerivO3CPU. > > > > Thanks > > Arun KP > > ___ > > 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] Simulation does not stop, SE mode, 2 cpus, DerivO3CPU, ruby memory
Hi Arun, "I started using ruby memory model after reading from gem5 email archive that classic memory does not work with multicore DerivO3CPU.": I didn't know this, where was this mentioned? I have just run an ARM pthread hello world on DerivO3CPU 2 cores and it worked on master. I reproduce your problem on X86 DerivO3CPU classic but not ARM DerivO3CPU. But a pthread hello world (single binary under --cmd that spanws threads) with 2 CPUs worked, I don't know the cause. If no one knows about this issue, you need to try and debug it :-) I would also open a ticket for this bug at https://gem5.atlassian.net/browse/GEM5 and move all discussion there. On Tue, Feb 18, 2020 at 4:43 AM Arun Kavumkal wrote: > > Hi, > I am trying to run gem5 in SE mode with number of cpus 2, cpu type > DerivO3CPU, and ruby memory model using following command, but the simulation > does not stop even after results are produced , ie "Hello world!" is printed > to stdout > > build/X86_MESI_Three_Level/gem5.opt configs/example/se.py -n 2 --ruby > --cpu-type=DerivO3CPU -c > 'tests/test-progs/hello/bin/x86/linux/hello;tests/test-progs/hello/bin/x86/linux/hello' > > I started using ruby memory model after reading from gem5 email archive that > classic memory does not work with multicore DerivO3CPU. > > Thanks > Arun KP > ___ > 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] Software Prefetch commands
Hi all, I have observed that software prefetch requests (SoftPFReq) comes in DL1. These commands appeared only in data caches, I have not seen them in instruction caches. The question is what are these requests? Does the gem5 recognize the compiler optimization regarding the software prefetching? Moreover, when the request forward to l2 and the response comes back the PC field is empty. Attached bellow two different traces for SoftPFReq and ReadReq. As you can see when the first access to l2 cache is made the PC is empty in SoftPFReq case. This is not happens in ReadReq. So which is the specialty of these requests? // - SoftPFReq - // 7917872449000: system.cpu.dcache: access: for SoftPFReq [1fd357a0:1fd357a0] miss, PC: 0x80270b2c 791787245: system.cpu.dcache: sendMSHRQueuePacket: MSHR SoftPFReq [1fd357a0:1fd357a0] 791787245: system.cpu.dcache: createMissPacket: created ReadSharedReq [1fd35780:1fd357bf] from SoftPFReq [1fd357a0:1fd357a0] 791787245: system.l2: access: for ReadSharedReq [1fd35780:1fd357bf] miss, PC: 0 // <--- PC has been lost 7917872460500: system.l2: sendMSHRQueuePacket: MSHR ReadSharedReq [1fd35780:1fd357bf] 7917872460500: system.l2: createMissPacket: created ReadSharedReq [1fd35780:1fd357bf] from ReadSharedReq [1fd35780:1fd357bf] 791787251: system.l2: recvTimingResp: Handling response ReadResp [1fd35780:1fd357bf] 791787251: system.l2: Block for addr 0x1fd35780 (PC: 0) being updated in Cache 791787251: system.l2: Block addr 0x1fd35780 (ns) (PC: 0) moving from state 0 to state: 7 (E) valid: 1 writable: 1 readable: 1 dirty: 0 | tag: 0x7f4 set: 0xd5e way: 0 791787251: system.l2: recvTimingResp: Leaving with ReadResp [1fd35780:1fd357bf] 7917872520500: system.cpu.dcache: recvTimingResp: Handling response ReadResp [1fd35780:1fd357bf] 7917872520500: system.cpu.dcache: Block for addr 0x1fd35780 (PC: 0) being updated in Cache 7917872520500: system.cpu.dcache: Block addr 0x1fd35780 (ns) (PC: 0) moving from state 0 to state: 7 (E) valid: 1 writable: 1 readable: 1 dirty: 0 | tag: 0x1fd35 set: 0x1e way: 0x1 7917872520500: system.cpu.dcache: recvTimingResp: Leaving with ReadResp [1fd35780:1fd357bf] 7917872917000: system.cpu.dcache: access: for ReadReq [1fd357a0:1fd357a7] hit state: 7 (E) valid: 1 writable: 1 readable: 1 dirty: 0 | tag: 0x1fd35 set: 0x1e way: 0x1, PC: 0x80270b28 7917872944000: system.cpu.dcache: access: for ReadReq [1fd357a0:1fd357a7] hit state: 7 (E) valid: 1 writable: 1 readable: 1 dirty: 0 | tag: 0x1fd35 set: 0x1e way: 0x1, PC: 0x80270b20 7917874192000: system.cpu.dcache: access: for ReadReq [1fd357a0:1fd357a7] hit state: 7 (E) valid: 1 writable: 1 readable: 1 dirty: 0 | tag: 0x1fd35 set: 0x1e way: 0x1, PC: 0x80270b20 7917874202000: system.cpu.dcache: access: for ReadReq [1fd357a0:1fd357a7] hit state: 7 (E) valid: 1 writable: 1 readable: 1 dirty: 0 | tag: 0x1fd35 set: 0x1e way: 0x1, PC: 0x80270b20 7917908658500: system.cpu.dcache: Evicting state: 7 (E) valid: 1 writable: 1 readable: 1 dirty: 0 | tag: 0x1fd35 set: 0x1e way: 0x1 (0x1fd35780) to make room for 0x17fc780 (0) 7917908658500: system.cpu.dcache: Create CleanEvict CleanEvict [1fd35780:1fd357bf] 7917908659500: system.cpu.dcache: sendWriteQueuePacket: write CleanEvict [1fd35780:1fd357bf] 7917908659500: system.l2: access:3 for CleanEvict [1fd35780:1fd357bf] hit state: 7 (E) valid: 1 writable: 1 readable: 1 dirty: 0 | tag: 0x7f4 set: 0xd5e way: 0, PC: 0 7917908659500: system.l2: handleTimingReqHit satisfied CleanEvict [1fd35780:1fd357bf], no response needed // -- ReadReq // 7917875422500: system.cpu.dcache: access:3 for ReadReq [1f952c90:1f952c97] miss, PC: 0x80270b5a 7917875423500: system.cpu.dcache: sendMSHRQueuePacket: MSHR ReadReq [1f952c90:1f952c97] 7917875423500: system.cpu.dcache: createMissPacket: created ReadSharedReq [1f952c80:1f952cbf] from ReadReq [1f952c90:1f952c97] 7917875423500: system.l2: access: for ReadSharedReq [1f952c80:1f952cbf] miss, PC: 0x80270b5a 7917875434000: system.l2: sendMSHRQueuePacket: MSHR ReadSharedReq [1f952c80:1f952cbf] 7917875434000: system.l2: createMissPacket: created ReadSharedReq [1f952c80:1f952cbf] from ReadSharedReq [1f952c80:1f952cbf] 7917875489000: system.l2: recvTimingResp: Handling response ReadResp [1f952c80:1f952cbf] 7917875489000: system.l2: Block for addr 0x1f952c80 (PC: 0x80270b5a) being updated in Cache 7917875489000: system.l2: Block addr 0x1f952c80 (ns) (PC: 0x80270b5a) moving from state 0 to state: 7 (E) valid: 1 writable: 1 readable: 1 dirty: 0 | tag: 0x7e5 set: 0x4b2 way: 0 7917875489000: system.l2: recvTimingResp: Leaving with ReadResp [1f952c80:1f952cbf] 7917875499500: system.cpu.dcache: recvTimingResp: Handling response ReadResp [1f952c80:1f952cbf] 7917875499500: system.cpu.dcache: Block for addr 0x1f952c80 (PC: 0x80270b5a) being updated in
