If you look in mem/cache/cache_impl.hh, you'll see recvTiming/Atomic/Function implementations. So, when a bus sends a sendTiming to the cache, the cache port on the other end of the bus port does a recvTiming and does the appropriate things.
Lisa On Tue, Dec 9, 2008 at 4:18 PM, Ryan Markley <[EMAIL PROTECTED]> wrote: > Hello Ali thanks for your answer, yes you are right I think that the > best way to solve my problem is looking specifically in the cache > code. I have been browsing the code in mem/cache/, but I have not seen > anything similar to the retry list that there is in the bus code. For > the bus, when the bus is busy then it puts the requests in a retry > list and after those petitions are serve in FCFS. Is there any similar > for the cache?, where is the code that management the petitions to the > cache?. > > Thanks. > > On Tue, Dec 9, 2008 at 6:56 AM, Ali Saidi <[EMAIL PROTECTED]> wrote: > > > > On Dec 8, 2008, at 3:49 PM, Ryan Markley wrote: > > > >> Hello, > >> > >> I have a system with 4 cpu and one L2 cache shared with all of the > >> cores, I am doing the simulations with the detail cpu. I am interested > >> in study how the cores access to the shared cache. I have been looking > >> in the code of mem/bus.cc and mem/bus.hh. In the file bus.cc there is > >> a function called recvTiming, this is the function that is used to > >> access to the bus and when the bus is busy the accesses are stored in > >> a retryList, but my question is: is this the function used to access > >> to the shared cache? > > Ultimately, yes. When it is able to it will call sendTiming() on the > > port that connects to the L2 cache. However, if you want to look at > > the L2 cache specifically, it would probably be better to look at the > > actual cache and put any instrumentation you like inside there. > > > >> or it is used only to access to the main memory. > >> I have been printing the accesses in the retryList , but I do not see > >> enough access from the different cores, that's why I am thinking that > >> maybe that retryList is not the retryList for the shared cache. > > The retryList only is populated when the bus cannot send the request > > immediately. If you're in the cache the request object has various > > fields that identify the CPU it's coming from (contextId() and > > threadId()), > > > >> And another question is there a way to assign a core per program in > >> full system mode, I know that is a linux question and not a M5 > >> simulator problem, but I would like to know if anybody knows a way to > >> assign a program to each core. > > You can do it with the sched_setaffinity() system call. Nate just > > pushed a change to the m5 binary (which stays on the disk image) that > > allows a syntax like m5 pin <cpu id> <program to run>, however you can > > just call sched_setaffinity from your workload if you like. However, I > > believe that the disk image we supply doesn't support that system > > call, so you would need to get the gentoo alpha disk image or create > > you own with a newer glibc on it. > > > > Ali > > > > _______________________________________________ > > m5-users mailing list > > [email protected] > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
