> On Sept. 9, 2016, 2:53 p.m., Gabor Dozsa wrote:
> > src/dev/net/dist_iface.cc, line 71
> > <http://reviews.gem5.org/r/3595/diff/1/?file=57400#file57400line71>
> >
> >     This change effectively disables the use of the start_tick parameter. 
> > It is because 'nextAt' is overwritten in SyncEvent::start() by the max tick 
> > of all participating gem5 - which will be 0 at the first global barrier (if 
> > we do not start the sync on pseudo op).   
> >     
> >     However, I think the pseudo op is a much better way to defer the sync 
> > start. Could you just remove the 'start_tick' option altogether?

I did a quick test and the start_tick approach still appears to work with this 
patch.

nextAt is assigned the value of start_tick for all the nodes and the switch in 
Synch::init().  SyncSwitch::progress() only updates nextAt(which determines the 
max tick of all paticipating processes) if it is less than send_tick.  At time 
zero this is not true, so the first global barrier will be scheduled at 
start_tick.


- Michael


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


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
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to