We've actually talked about adding this feature within our group. It's not a trivial task and currently it isn't a priority for our research, so it takes a back seat.
If you're willing to work on this for your own research, providing a patch or pull request would be very helpful. On Tue, Mar 26, 2013 at 5:03 PM, Eduardo Cruz <[email protected]>wrote: > But forgetting DRAMsim. > A way to simply simulate NUMA, you could instantiate several DRAM > controllers, one per processor. > Then, the memory addrs could be interleaved among the controllers. > GEMS does something similar. > Is it difficult to implement this? > I believe that this would be an important addition, because most HPC > systems use several memory controllers. > > 2013/3/26 Paul Rosenfeld <[email protected]>: > > Yeah DRAMSim2 basically unhooks the default "the request is done" signal > and > > rehooks it to a callback function that is called by DRAMSim2. > > > > But I guess what I'm getting at is that the latency to "get to" a remote > > memory controller should be higher -- so at some point you'd have to add > > some latency somewhere in order to simulate NUMA. > > > > > > > > On Tue, Mar 26, 2013 at 4:06 PM, Brendan Fitzgerald > > <[email protected]> wrote: > >> > >> I'd need to look into the interface between DRAMSim2 and MARSS to see > >> what, if any, changes would need to be made. > >> > >> If DRAMSim2 just intercepts the send to lower request, I don't think > there > >> would need to be any changes in MARSS. > >> > >> > >> On Tue, Mar 26, 2013 at 3:59 PM, Paul Rosenfeld <[email protected]> > >> wrote: > >>> > >>> At the moment this isn't possible with DRAMSim2 either. Due to some > poor > >>> choices in terms of how global variables are handled, you actually > can't > >>> instantiate multiple instances of DRAMSim2 in a single simulation (or > at > >>> least not heterogeneous configurations). While I don't have time at the > >>> moment, it is possible to fix this issue with some tedious but simple > >>> changes. > >>> > >>> If such a thing was possible from the perspective of DRAMSim2, I'm not > >>> entirely sure what you'd have to do on the MARSS side of things to get > this > >>> working. You could just stuff X DRAMSim2 instances into the marss > >>> memoryController.cpp file and just pick one when a request arrives. But > >>> that's not really NUMA, right? You'd have to implement some QPI-esque > >>> interface where CPUs can send requests to one another (correct me if > I'm > >>> wrong, I don't know much about how this stuff is typically done in > >>> hardware). > >>> > >>> > >>> > >>> On Tue, Mar 26, 2013 at 3:28 PM, Eduardo Cruz < > [email protected]> > >>> wrote: > >>>> > >>>> Ok, thank for the awnser. > >>>> What about the usage of MARSS with the integrated DRAMsim support, > >>>> would it then allow multiple memory controllers? > >>>> > >>>> 2013/3/26 Brendan Fitzgerald <[email protected]>: > >>>> > Hi, > >>>> > > >>>> > We currently don't have the ability to have multiple memory > >>>> > controllers. The > >>>> > memoryController uses a very simple model of having 64 banks and > >>>> > determining > >>>> > which bank the address is by looking at six bits of the physical > >>>> > address. > >>>> > > >>>> > Brendan > >>>> > > >>>> > On Tue, Mar 26, 2013 at 2:44 PM, Eduardo Cruz > >>>> > <[email protected]> > >>>> > wrote: > >>>> >> > >>>> >> Hello. > >>>> >> I'm making some experiments with NUMA machines and I think MARSS > has > >>>> >> the necessary features for my tests. > >>>> >> However, I haven't seen any sample config file of machines with > more > >>>> >> than 1 memory controller. > >>>> >> Does MARSS supports that? > >>>> >> If it does, how does MARSS spread the addresses along the memory > >>>> >> controllers? > >>>> >> In which file/function the target memory controller is selected? > >>>> >> I have some other questions, but if you could help me first with > >>>> >> these > >>>> >> ones I would really appreciate. > >>>> >> > >>>> >> Thanks in advance > >>>> >> > >>>> >> -- > >>>> >> Eduardo Henrique Molina da Cruz > >>>> >> PhD student > >>>> >> Parallel and Distributed Processing Group > >>>> >> Federal University of Rio Grande do Sul (UFRGS) > >>>> >> > >>>> >> _______________________________________________ > >>>> >> http://www.marss86.org > >>>> >> Marss86-Devel mailing list > >>>> >> [email protected] > >>>> >> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel > >>>> > > >>>> > > >>>> > >>>> > >>>> > >>>> -- > >>>> Eduardo Henrique Molina da Cruz > >>>> PhD student > >>>> Parallel and Distributed Processing Group > >>>> Federal University of Rio Grande do Sul (UFRGS) > >>>> > >>>> _______________________________________________ > >>>> http://www.marss86.org > >>>> Marss86-Devel mailing list > >>>> [email protected] > >>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel > >>> > >>> > >> > > > > > > -- > Eduardo Henrique Molina da Cruz > PhD student > Parallel and Distributed Processing Group > Federal University of Rio Grande do Sul (UFRGS) >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
