Hi Brendan &Tyler, I have compiled MARSS with C=32 and ran both shared_l2 and private_L2. Unfortunately both of them crashed. Please find below the assertions I got with the simulation of each of them:
shared_l2: ERROR: guest physical address 0xfffffff0 is out of bounds 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. private_L2: 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. I got the above assertions for the simulated machines consistently. I tried to simulate each one thrice. Kindly let me know if you need any other data. Thanks, karthik On Sun, Jul 13, 2014 at 10:51 PM, Brendan Fitzgerald <[email protected]> wrote: > Compile with c=32 then run either shared_l2 or private_L2 since they are > configured with OoO cores. > > By sample he means it's the one we provide. The core doesn't reflect an > actual machine, but it's close. > > > On Sun, Jul 13, 2014 at 9:25 PM, karthik vm <[email protected]> wrote: >> >> Hi Tyler, >> >> I am not quite clear what you mean by sample OoO configurations. >> Currently the 'shared_l2' or 'private_L2' machine configurations are >> configured as OoO cores. So you want me to compile MARRS for 32 cores >> and simulate one of these machines? Can you clarify? Thanks. >> >> Regards, >> karthik >> >> On Sat, Jul 12, 2014 at 2:12 PM, <[email protected]> wrote: >> > 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 > > _______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
