Karthik, Which benchmark(s) are you running? Kernel version? Are you using one of the stock images? This shouldn't happen in a stock configuration like this...
Tyler > Hi, > > Thanks a lot for taking your time to help me out amidst your busy > schedule. Do you need any more data from my side? Kindly let me know. > > Regards, > karthik > > On Mon, Jul 14, 2014 at 5:38 PM, karthik vm <[email protected]> wrote: >> 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
