Karthik, Can you try one of the sample OoO configurations? The configuration files are sensitive and currently not fully checked for validity.
Compile with: scons c=32 Then use the 'shared_l2" or 'private_L2' machine configuration (be aware of the capitalization differences...) That should give you a 32-core non-SMT configuration. Tyler > Hi Tyler, > > Thanks for your immediate reply. Great to know that MARSS is suited > for analyzing lock contention. > > Basically I was trying to simulate the 'private_L2' machine from the > 'default' configuration file with enable-kvm switch in qemu. The > configuration of 'cores' in private_L2 is below: > > cores: > - type: ooo > name_prefix: ooo_ > > Since there are no option for # of threads. I guess the cores are > single threaded or non SMT. Anyway to enforce this I added the threads > option as below: > > cores: > - type: ooo > name_prefix: ooo_ > option: > threads: 1 > > When I ran the simulation I get the same error again: > qemu-system-x86_64: ptlsim/build/core/ooo-core/ooo-pipe.cpp:2054: int > ooo::ReorderBufferEntry::commit(): Assertion `ctx.get_cs_eip() == > uop.rip' failed. > > Then I tried to change the core type from 'ooo' to 'atom' which is non > SMT in the machine. Please find the configuration below: > > cores: > - type: atom > name_prefix: atom_ > option: > threads: 1 > > Now also I see that the simulation stops with the following error > shortly after it started: > qemu-system-x86_64: ptlsim/build/core/atom-core/atomcore.cpp:2128: > void atom::AtomThread::dtlb_walk(): Assertion `dtlb_miss_addr' failed. > > Kindly let me know your comments. > > Thanks, > karthik > > On Thu, Jul 10, 2014 at 11:50 AM, <[email protected]> wrote: >> Karthik, >> >> This assertion: >> ooo::ReorderBufferEntry::commit(): Assertion `ctx.get_cs_eip() == >> uop.rip' >> failed. >> >> is a long-living bug in the current MARSS code. I believe it may been >> linked to SMT-based configurations, but I have not had the time to look >> into it. If your simulated machine uses SMT, can you try disabling SMT >> and >> please regenerate checkpoints and try again? >> >> As for your second question, MARSS is definitely suited to giving your >> more statistics than other options (i.e., instrumenting the kernel, >> using >> hardware/machine counters, etc.). If you need detailed, hardware-level >> statistics relating to lock contention, you can easily instrument the >> MARSS code base with some heuristics/counters that suit your research. >> >> Tyler >> >>> Hi, >>> >>> I am trying to use MARlSS for analyzing lock contention in >>> multi-threaded apps and in linux OS code. I have successfully built >>> the simulator and able to simulate the cores. Some of the questions I >>> have are: >>> >>> 1) When I try to run MARSS configured with large number of cores(e.g >>> 32), the simulation is very slow. From the discussion here >>> "http://article.gmane.org/gmane.comp.emulators.marss86/112/match=enable+kvm"; >>> I get that atleast for creating checkpoints we can use KVM which will >>> be much faster. But I do not understand where should we enable the >>> KVM? I tried the following: >>> >>> $ qemu/qemu-system-x86_64 -enable-kvm -m [memory_size] -hda >>> [path-to-qemu-disk-image] >>> >>> Then in qemu monitor mode I configured the simulator as follows: >>> simconfig -run -machine private_L2 >>> >>> But shortly after the simulator starts I get the following error: >>> qemu-system-x86_64: ptlsim/build/core/ooo-core/ooo-pipe.cpp:2054: int >>> ooo::ReorderBufferEntry::commit(): Assertion `ctx.get_cs_eip() == >>> uop.rip' failed. >>> >>> Can someone point me what I miss here and what Avadh was talking about >>> enabling KVM? >>> >>> 2) From the mailing list discussion >>> (http://www.mail-archive.com/marss86-devel%40cs.binghamton.edu/msg01882.html) >>> I see that MARSS runs the cores concurrently. Hence I believe MARSS >>> can simulate the lock contentions in both application & OS code needed >>> for my research. Kindly let me know your comments for confirmation. >>> >>> Thanks for your time, >>> karthik >>> >>> _______________________________________________ >>> 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
