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
