> On Aug. 30, 2016, 3:39 p.m., Michael LeBeane wrote:
> > Any comments on this patch?

I just have some high level question before goring through the code:

Can you explain the use-case for this patch? Probably it means to speed up the 
simulation but why do we need to switch on/off synchronization at some points?

When you suspend CPUs, then how your simulation will gaurantee forward 
progress? Doesn't this lead to dead-lock in some situations?

Thanks.


- Mohammad


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3595/#review8693
-----------------------------------------------------------


On Aug. 4, 2016, 4:51 p.m., Michael LeBeane wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3595/
> -----------------------------------------------------------
> 
> (Updated Aug. 4, 2016, 4:51 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> -------
> 
> Changeset 11561:1414a40eb1e2
> ---------------------------
> dev: Add m5 op to toggle synchronization for dist-gem5.
> This patch adds the ability for an application to request dist-gem5 to begin/
> end synchronization using an m5 op.  When toggling on sync, all nodes agree on
> the next sync point based on the maximum of all nodes' ticks.  CPUs are
> suspended until the sync point to avoid sending network messages until sync 
> has
> been enabled.  Toggling off sync acts like a global execution barrier, where
> all CPUs are disabled until every node reaches the toggle off point.  This
> avoids tricky situations such as one node hitting a toggle off followed by a
> toggle on before the other nodes hit the first toggle off.
> 
> 
> Diffs
> -----
> 
>   configs/common/Options.py 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/arch/x86/isa/decoder/two_byte_opcodes.isa 
> 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/dev/net/Ethernet.py 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/dev/net/dist_etherlink.cc 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/dev/net/dist_iface.hh 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/dev/net/dist_iface.cc 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/dev/net/dist_packet.hh 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/dev/net/tcp_iface.hh 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/dev/net/tcp_iface.cc 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/sim/pseudo_inst.hh 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/sim/pseudo_inst.cc 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   util/m5/m5op.h 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   util/m5/m5op_x86.S 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   util/m5/m5ops.h 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
> 
> Diff: http://reviews.gem5.org/r/3595/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Michael LeBeane
> 
>

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to