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
