Oh, I forgot to ask that if I also need to build hierarchical switch topology for the MOSI_SMP_bcast protocol to guarantee the order required or the current GEM5 supports that already....Thanks.
Best, Jinzhu On Fri, Jul 27, 2012 at 3:20 PM, gem5 gem5 <gem5.user....@gmail.com> wrote: > Hi Tushar, > > Your suggestions are really helpful. Thank you very much! For now, I think > I will take Pt2Pt as the basic topology to work with since it has all the > connections. I think I can view it the same way as the single write > multiple read shared-bus crossbar. I just need to create a broadcast > protocol for it. > > You are right, MOESI_hammer is not a good choice since it's essentially a > directory protocol. MOSI_SMP_bcast is a much better reference, although I > am not sure how to modify that since it is for GEMS' hierarchical switch > and it also has some directories inside. Hope I will figure it out. > > Do you think this is the right direction to go? Thanks a lot again! > > Best, > > Jinzhu > > On Fri, Jul 27, 2012 at 12:44 AM, Tushar Krishna <tus...@csail.mit.edu>wrote: > >> Hi Jinzhu, >> Ok so I see two components in your design: >> (1) broadcast-based coherence protocol >> (2) shared-bus based crossbar >> >> For (1) you want every message to be a broadcast. I am not sure if >> MOESI_hammer is the correct protocol to use as your starting point. The >> reason is that MOESI_hammer is essentially a directory protocol, with the >> directory having no state. So every cache miss first goes to its home node, >> and the home node then performs a broadcast to all other caches, and then >> the owner responds to the requestor. >> What you need from what I understand is the cache miss to directly be >> broadcast, like on a bus, and the owner then responding. >> The original GEMS distribution actually came with a broadcast protocol >> for a bus, called MOSI_SMP_bcast. >> You could try to look at that from the GEMS repo, and perhaps code up >> something similar in gem5. >> Or stick to MOESI_hammer for now, but you will need to modify it to model >> the kind of protocol you want. >> >> For (2), you first need to create a topology. >> You can look at configs/topologies to see how topologies are created. >> The routers in the topology get modeled either as garnet-routers or >> simple-routers. >> You can choose to work with either garnet or the default simple network. >> Garnet will however model a 4-5 stage router pipeline. In my paper I had >> optimized this pipeline, and added an mXbar in the switch traversal stage. >> Also note that the released version of garnet does not have broadcast >> support, i.e. a broadcast is converted into individual messages at the >> source, one for each destination and sent out. >> If you use the simple network, the switch models there can handle >> broadcasts. You could perhaps use that as a starting point and then edit >> the code to model the crossbar you want. >> >> cheers, >> Tushar >> >> >> On Jul 26, 2012, at 8:33 PM, gem5 gem5 wrote: >> >> Tushar, >> >> The reason I am modifying the protocol is that I want to implement a >> shared-bus based crossbar where each node has its own dedicated write >> channel and other nodes listen to it. However, I see that ruby does not >> support hardware broadcast, so modifying the protocol seems to me the only >> way to implement this. I think by modifying all the messages to be >> broadcast messages can solve this. It would be really helpful if you could >> provide me more information how to implement this kind of topology. I think >> mXbar is very very close to what I wanna do. Thank you very much! >> >> Best, >> >> Jinzhu >> >> On Thu, Jul 26, 2012 at 7:30 PM, Tushar Krishna <tus...@csail.mit.edu>wrote: >> >>> Hi Jinzhu, >>> Why do you want to broadcast to L1s and the directories? Just to add >>> more messages in the network? MOESI_hammer inherently broadcasts to all L1s >>> which gives you a broadcast to all nodes. I don't think you should mess >>> with the protocol, unless you have a strong justification for why those >>> extra messages are needed: example you come up with some new protocol that >>> sends more broadcasts instead of tracking some state etc… In which case, >>> yes you would have to define extra transitions to handle the extra messages. >>> >>> The two broadcast based protocols provided with gem5 are MOESI_hammer >>> (where a directory broadcasts to all L1s) and MOESI_CMP_token, where L1's >>> broadcast to all L2s … >>> >>> cheers, >>> Tushar >>> >>> >>> On Jul 26, 2012, at 6:21 PM, gem5 gem5 wrote: >>> >>> Hi Tushar, >>> >>> Thanks for your reply! I think you are right. I need to deal with those >>> extra messages. Any suggestions how to do that? Should I define some new >>> transitions and get rid of those messages? >>> >>> I have read your 1 to many paper before. If I want to implement some >>> crossbar topology which supports broadcast like mXbar, do you think >>> modifying the protocol is the right way to do or there is some other better >>> method? Thank you very much for your help. >>> >>> Best, >>> >>> Jinzhu >>> >>> >>> >>> On Thu, Jul 26, 2012 at 12:53 PM, Tushar Krishna >>> <tus...@csail.mit.edu>wrote: >>> >>>> The error has nothing to do with the virtual network being ordered or >>>> not. >>>> If you look at MessageBuffer.hh, line 131, a setOrdering function needs >>>> to be called for each MessageBuffer. >>>> This is called from the coherence protocol's generated files. [The >>>> ordering itself might be true or false depending on the vnet, but this >>>> function has to be called for the message buffer to be valid]. >>>> >>>> If all you have changed in the protocol is to broadcast to all L1's and >>>> directories, instead only only to L1's, you also need to account for what >>>> happens when these directories receive these messages. My guess is that >>>> these messages are being inserted into some message buffer that is not part >>>> of the protocol specifications and hence this error shows up. >>>> >>>> >>>> - Tushar >>>> >>>> >>>> On Jul 25, 2012, at 5:29 PM, gem5 gem5 wrote: >>>> >>>> > Hi all, >>>> > >>>> > I want to modify MOESI_hammer protocol to broadcast all the messages. >>>> Since multicast is supported, I think it's possible to do this. I got some >>>> problem with my first step. When I modify >>>> out_msg.Destination.broadcast(MachineType:L1Cache); to be >>>> out_msg.Destination.broadcast() which I assume means to broadcast to all >>>> nodes, inside of action(fn_forwardRequestIfNecessary, "fn", desc="Forward >>>> requests if necessary"), I got some error like this when run the >>>> rubynetwork tester with Pt2Pt topology: >>>> > >>>> > panic: Ordering property of has not been set >>>> > @ cycle 40 >>>> > [enqueue:build/X86_SE/mem/ruby/buffers/MessageBuffer.cc, line 165] >>>> > Memory Usage: 241400 KBytes >>>> > Program aborted at cycle 40 >>>> > Abort >>>> > >>>> > I tried to set the corresponding virtual network forwardFromDir's >>>> ordered="true", but still I cannot get rid of this error. Any help will be >>>> appreciated. Thanks a lot! >>>> > >>>> > Jinzhu >>>> > >>>> > >>>> > _______________________________________________ >>>> > gem5-users mailing list >>>> > gem5-users@gem5.org >>>> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> gem5-users@gem5.org >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> gem5-users@gem5.org >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> gem5-users@gem5.org >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
