> On Aug. 30, 2016, 3:39 p.m., Michael LeBeane wrote: > > Any comments on this patch? > > Mohammad Alian wrote: > 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.
The use case is, like you inferred, to speed up simulation when you don't need to synchronize. There is currently a method to support this using ticks, but I prefer to use source code annotations. The CPUs suspend until the largest tick of all participating CPUs is reached. This is to ensure that we really have started synchronizing after executing the pseudo-op, else we could start sending network messages before we are ready. I don't see a deadlock situation here, can you elaborate on your concern? - Michael ----------------------------------------------------------- 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
