2012/1/31 Neumann, Stefan <[email protected]> > Hi,**** > > ** ** > > thank you. I didn’t noticed the last checkins.**** > > The kernel-loop issue seems to be fixed. I restarted my regression and all > 81 simulations are up and running.**** > > ** >
Good to hear that. I am cleaning up some code and then planning to do a next bug fix release with latest fixes so people can pull changes from 'master' branch. > ** > > Do you have any suggestions regarding the entry point for the simulation?* > *** > > Why does the simulation always start at a different rip although the > ptlcalls are embedded in the source code of the benchmark?**** > > ** > Its because the way QEMU does *faster* emulation. When a ptlcall is issued it will generate set a flag in CPU to stop execution. In QEMU the point at which this flag is checked is at the end of each basic-block and for optimization purpose they patch the basic blocks to execute *taken* branch with in-frequent checks. Because of this mechanism (which I haven't understood totally) it introduces the uncertainty about when the CPU execution will stop. But the difference will be very small so if you run your simulations long enough (more than 100mil instructions) this will not affect your final results. - Avadh > ** > > Regards,**** > > Stefan**** > > ** ** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *avadh patel > *Sent:* Tuesday, January 31, 2012 4:22 PM > *To:* Stefan Neumann > *Cc:* [email protected] > *Subject:* Re: [marss86-devel] MMIO mechanism to switch to simulation**** > > ** ** > > ** ** > > On Mon, Jan 30, 2012 at 11:18 AM, Stefan Neumann < > [email protected]> wrote:**** > > Hi, > > I've started using MARSSx86 and have some issues with the simulation. > I am aware of the fact that the simulation itself isn't deterministic, but > I do not really understand the mechanism to switch from emulation to > simulation mode an vice versa. > > For my simulations I've compiled the SPEC CPU2006 benchmarks using > ptlcalls. (ptlcall_switch_to_sim and ptlcall_switch_to_native [using the > -stop command]). To shorten the simulation time I've inserted the calls > after the initialization phase of each benchmark and jump back to emulation > after the calculation. > All executables are statically linked. > > To run the the simulation I am using the create_checkpoints/run_bench > scripts. > Checkpoints are created using: > 'cd spec2006bins_static_ptlcall/Xalan/ > ~/create_checkpoint Xalan; ./Xalan -v test.xml xalanc.xsl; echo $?; > ~/stop_sim; shutdown -P now; > Simconfig: > -logfile results5/bwaves.log > -logfilesize 589934592 > -loglevel 999 > -stats results5/bwaves.yml > -machine single_core > Executed command: > qemu-system-x86_64 -m 4G -serial pty -nographic -drive > cache=unsafe,file=spec2006_ptlcalls.qcow2 -simconfig /tmp/Xalan.simconfig > -loadvm Xalan -snapshot > > Xalan.out content: > ptlsim_ptlcall_init: mapped PTLcall MMIO page at phys 0x8fffff000, virt > 0x2ab8e24cc000 [this is the switch_to_sim call] > > What I do not understand is that although I make the ptlcalls during the > execution of the benchmark, the simulation always starts at a different > instruction. I would expect is that after the the MMIO access the emulator > would switch to simulation mode immediately to execute the subsequent > instruction. > > [Example: Xalan 2 different runs] > > Completed 0 cycles, 0 commits: 0 > Hz, 0 insns/sec: rip 0000000000690ee0 > vs. > Completed 0 cycles, 0 commits: 0 > Hz, 0 insns/sec: rip ffffffff81013092 > > Furthermore I also happens (quite often) that after the switch to > simulation, the simulation does not execute the benchmark at all, but > instead seems to stay in some kind of endless loop in kernel space.**** > > We have recently pushed some fixes on feature branch that is being tested. > Can you pull changes from 'features' branch from github?**** > > The commit id that tries to solve this issue is : > 8e7ca4ba7eb4041c154f4423ab46ebb7b2dfb7ea**** > > ** ** > > - Avadh**** > > **** > > Does anybody know what is going on there, or can give me a hint on how the > whole MMIO switching mechanism works? > > Out of 81 benchmark runs, 34 got stuck in this kernel loop. (not the idle > loop) > > Thanks and greetings from Germany. > Stefan > > _______________________________________________ > http://www.marss86.org > Marss86-Devel mailing list > [email protected] > https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel**** > > ** ** > > > -------------------------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 > > _______________________________________________ > http://www.marss86.org > Marss86-Devel mailing list > [email protected] > https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel > >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
