Dear all,

I'm trying to simulate PARSEC 2.0 workload using gem5 (x86, linux smp
version, FS mode).
As I need to change cache coherence protocol and topology, Ruby is used
instead of classic memory system.

However, with this setting I had several problems.
1. Cannot use atomic CPU, which is useful for fast-forwarding and
checkpointing.
2. Only MOESI_hammer protocol supports checkpointing.

MOESI_hammer was easy to use; take checkpoint using timing CPU, and restore
from it using detailed CPU.
Except for some workloads such as blackscholes, it seemed to work.

However, for the other protocols, I couldn't use this method. So I just
'switched' CPU rather than checkpointing.
I thought this will work, because even if cache flush operation is not
implemented for these protocols, the memory system will be maintained
during the CPU switching. See (*) if you want to know my detailed reasoning.

Unfortunately, after switching, some configurations and workloads led to
either 'panic: Possible Deadlock detected. Aborting!' error or
(practically) infinite execution, although roi_end annotated with m5_exit
call should make the simulator end.

Would somebody help me solve this problem? Thank you in advance.

Best regards,
Jae-Eon

----
(*) Supplement
I think correct checkpointing in gem5 at least requires two things:
1. Drain: Ensure that there is no in-flight packet
2. Serialization/unserializaion: Data in the cache should be
serialized/unserialized.

The first makes sure each module can be serialized/unserialized
independently, which is useful for modular structure like gem5 to
checkpoint easily.
I think this functionality is implemented in protocol-independent
RubyPort.{cc,hh} and RubyMemoryControl.{cc,hh} source files, which is
protocol independent.

The second is not to lose data which can only be found from the cache; one
way is to serialize/unserialize them directly, and the other way is to
delegate this obligation to the lower level.
The current gem5 seems to use the delegation, and for this cache flush
operation is required.
Sadly, only MOESI_hammer can do this now. (http://www.m5sim.org/Checkpoints)

In conclusion, this implies that switching, which requires drain but not
serialization/unserialization, will be successfully done with all protocols.
----
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to