> 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 [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
