No :). I'll elaborate in the other thread... On Thu, Jul 2, 2015 at 5:35 PM Andreas Hansson <[email protected]> wrote:
> Hi Steve, > > Shared-memory MultiIface would be synchronising the gem5 instances on a > coarse granularity, corresponding to a link delay (it is a number of > non-coherent machine instances). The multi-threaded event-queue > implementation has to synchronise all event queues on every single memory > access (assuming a coherent system). Is that what you were referring to? > > Andreas > > On 02/07/2015 10:54, "gem5-dev on behalf of Steve Reinhardt" > <[email protected] on behalf of [email protected]> wrote: > > > > > > >> On June 29, 2015, 12:55 p.m., Tony Gutierrez wrote: > >> > Firstly, thanks for this patch, this is really nice work. > >> > > >> > I have only done a cursory review of this patch so I'm still looking > >>over the code in more detail, but I thought I'd share some of my initial > >>thoughts to get the conversation going on this since it seems to have > >>stagnated. > >> > > >> > Reiterating Nilay's point: there are a lot of style issues that need > >>to be fixed. > >> > > >> > It seems like this would be useful for large-scale systems, but could > >>you give some idea how easily one could derive from the multi link/iface > >>objects for use with a multi-threaded aproach, thereby avoiding > >>socket-based communication? E.g., if I wanted to model small/medium > >>scale distributed systems consisting of ~10s of nodes on a single host > >>machine. It would be nice if multi-gem5 and a multi-threaded approached > >>were unified and built off the same base classes. > >> > > >> > For the TCP server, have you thought about an event-based approach, > >>i.e., libevent or libev as opposed to using poll()? > >> > >> Gabor Dozsa wrote: > >> Thank you for reviewing the patches! > >> > >> Regarding a possible thread based implementation, the purpose of > >>the pure virtual MultiIface class is exactly to allow different > >>implementations for the low level underlying messaging system. The > >>tcp_iface.[hh|cc]/tcp_server.[hh|cc] files provide a socket based > >>implementation but it should be possible to provide a > >>multi-threaded/shared memory based implementation as well without any > >>major changes in the MultiEtherlink/MultiIface classes. > >> > >> Using libevent/libev is a very good idea as a future optimization > >>for large scale multi-gem5 simulations with hundreds of gem5 processes. > >>The poll() interface could definitely be a bottleneck beyond a few dozen > >>sockets. > > > >What would be the benefit of a shared-memory implementation of MultiIface > >vs. the existing multithreaded multiple event queue support? > > > > > >- Steve > > > > > >----------------------------------------------------------- > >This is an automatically generated e-mail. To reply, visit: > >http://reviews.gem5.org/r/2826/#review6647 > >----------------------------------------------------------- > > > > > >On June 24, 2015, 4:56 p.m., Curtis Dunham wrote: > >> > >> ----------------------------------------------------------- > >> This is an automatically generated e-mail. To reply, visit: > >> http://reviews.gem5.org/r/2826/ > >> ----------------------------------------------------------- > >> > >> (Updated June 24, 2015, 4:56 p.m.) > >> > >> > >> Review request for Default. > >> > >> > >> Repository: gem5 > >> > >> > >> Description > >> ------- > >> > >> Multi gem5 is an extension to gem5 to enable parallel simulation of a > >> distributed system (e.g. simulation of a pool of machines > >> connected by Ethernet links). A multi gem5 run consists of seperate gem5 > >> processes running in parallel (potentially on different hosts/slots on > >> a cluster). Each gem5 process executes the simulation of a component of > >>the > >> simulated distributed system (e.g. a multi-core board with an Ethernet > >>NIC). > >> > >> The patch implements the "distributed" Ethernet link device > >> (dev/src/multi_etherlink.[hh.cc]). This device will send/receive > >> (simulated) Ethernet packets to/from peer gem5 processes. The interface > >> to talk to the peer gem5 processes is defined in dev/src/multi_iface.hh > >>and > >> in tcp_iface.hh. > >> > >> There is also a central message server process > >>(util/multi/tcp_server.[hh,cc]) > >> which acts like an Ethernet switch and transfers messages among the > >>gem5 peers. > >> > >> A multi gem5 simulations can be kicked off by the > >>util/multi/gem5-multi.sh > >> wrapper script. > >> > >> Checkpoint support will follow in a subsequent patch. > >> > >> > >> Diffs > >> ----- > >> > >> src/dev/Ethernet.py d02b45a554b52c68cce41e1b3895fb8582a639dd > >> src/dev/SConscript d02b45a554b52c68cce41e1b3895fb8582a639dd > >> src/dev/etherpkt.hh d02b45a554b52c68cce41e1b3895fb8582a639dd > >> src/dev/etherpkt.cc d02b45a554b52c68cce41e1b3895fb8582a639dd > >> src/dev/multi_etherlink.hh PRE-CREATION > >> src/dev/multi_etherlink.cc PRE-CREATION > >> src/dev/multi_iface.hh PRE-CREATION > >> src/dev/multi_iface.cc PRE-CREATION > >> src/dev/multi_packet.hh PRE-CREATION > >> src/dev/multi_packet.cc PRE-CREATION > >> src/dev/tcp_iface.hh PRE-CREATION > >> src/dev/tcp_iface.cc PRE-CREATION > >> util/multi/Makefile PRE-CREATION > >> util/multi/bootscript.rcS PRE-CREATION > >> util/multi/gem5-multi.sh PRE-CREATION > >> util/multi/tcp_server.hh PRE-CREATION > >> util/multi/tcp_server.cc PRE-CREATION > >> > >> Diff: http://reviews.gem5.org/r/2826/diff/ > >> > >> > >> Testing > >> ------- > >> > >> > >> Thanks, > >> > >> Curtis Dunham > >> > >> > > > >_______________________________________________ > >gem5-dev mailing list > >[email protected] > >http://m5sim.org/mailman/listinfo/gem5-dev > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2548782 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
