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
