The problem is that in the statistics I only see a final number I need to capture the evolution of them. I am printing the retrylist but I do not see many accesses but I think that that is a problem of my configuration. When you say adding another port, do you mean that I can connect the cache to that port and in that way it will be easier to see what I want?. I do not think that is so complex I just need a way to identify the cache and then in the recvTiming function of bus.cc I can capture the accesses to L2 cache with pkt->req->getCpuId() or with other field and the CPU with pkt->req->getCpuNum(), in this way I can get the accesses, is this right?.
Also I think that in the place where the statistics are collected I will be able to capture the accesses. In somewhere in the code to compute the statistics I think that you guys do the same thing that I have to do. Can you provide more information about how the statistics are compute?. Thanks for your effort in helping me. On Tue, Dec 16, 2008 at 4:27 PM, Ali Saidi <[email protected]> wrote: > For most of the information you want should be provided by the l2, and > l1 cache statistics. If you want exact data about the retry list that > is more complex. You could add an additional port to the bus that was > the the l2 cache, short of that no elegant solution comes to mind. > > Ali > > On Dec 16, 2008, at 6:53 PM, Ryan Markley wrote: > >> Hello, the thing that I have to do I think is not so complex once you >> know where to look, basically I have to get stats about the number of >> accesses to the shared cache (L2 cache) between the several cpus. >> That's why I said how can I identify the L2 cache and the cpu, in that >> way I can store the accesses and the cycles and get the stats that I >> want. My interest in the retry list comes to know how those accesses >> are clustered. >> >> Thanks. >> >> On Tue, Dec 16, 2008 at 3:38 PM, Ali Saidi <[email protected]> wrote: >>> Yes and yes. >>> >>> As you said the interface is very transparent/generic so there >>> isn't a >>> mechanism to do what you ask. I think we would need some more >>> information about what you're trying to do at a high level before we >>> could propose an alternate solution. >>> >>> Ali >>> >>> On Dec 16, 2008, at 6:25 PM, Ryan Markley wrote: >>> >>>> Hello Ali thanks for your confirmation. Can you give me the last >>>> confirmation. The retryList that is in void Bus::recvRetry(int >>>> id), in >>>> the bus.cc file, is the list in which all the failed attempts from >>>> any >>>> devices are stored?. And finally it seems that the management >>>> process >>>> between devices is very transparent and the mechanism is always the >>>> same between all the different devices in the system, using the >>>> functions recvRetry() and sendRetry, is this true for all the memory >>>> devices and cpu's or is there any exception?. >>>> >>>> And finally another question can you give me an advice in which >>>> fields >>>> should I use to differentiate the different caches, I only know >>>> gedId(). I have seen that each device has a different port number, >>>> but >>>> is there any way to know what port belongs to each cache?. >>>> >>>> Thanks. >>>> >>>> On Tue, Dec 16, 2008 at 11:20 AM, Ali Saidi <[email protected]> wrote: >>>>> >>>>> On Dec 16, 2008, at 12:12 PM, Bob Nagel wrote: >>>>> >>>>>> Hello Clint thanks for your answer I have been exploring the code >>>>>> and >>>>>> you are right the things work as you explained. But I have another >>>>>> problem, what happen when the bus is not busy but is the L2 cache >>>>>> the >>>>>> one that is busy. In my system I have a shared L2 cache between >>>>>> all >>>>>> the cores, when one core attempts to access and the shared cache >>>>>> is >>>>>> busy do you know what happen?. I have not been able to understand >>>>>> how >>>>>> the simulate manage this situations. >>>>> Exactly the same way, the bus being busy and the target being busy >>>>> both result in the sender failing to send the transmission at that >>>>> time and a retry being sent at a later time. >>>>> >>>>>> >>>>>> >>>>>> I beleive that the situation is something similar than before, >>>>>> when a >>>>>> core attempts to access to the cache and it is busy then it enters >>>>>> in >>>>>> a DcacheRetry state and after a while the bus tries to send again >>>>>> the >>>>>> petition to the cache until it is successful. But I have several >>>>>> questions, when does the bus send again the petition?, is there a >>>>>> singal from the cache to the bus that indicates that now the cache >>>>>> is >>>>>> free a then the bus can attempt to send a petition.? >>>>> Yes, the cache sends a sendRetry() to the bus which then calls >>>>> sendRetry() on the first waiter. >>>>> >>>>>> And if for >>>>>> example there are several petitions from different cores what is >>>>>> the >>>>>> policy that the bus uses in order to manage all the accesses >>>>>> FCFS?. >>>>>> Sorry for all of these questions adn thanks for the help. >>>>> Yes, it is FCFS. >>>>> >>>>> Ali >>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2008/12/15 Clint Smullen <[email protected]>: >>>>>>> Fundamentally, no device should continuously try to send a >>>>>>> request >>>>>>> again. The behavior for "most" memory system objects currently in >>>>>>> M5 >>>>>>> is to "block" the port and wait for a retry message to be sent by >>>>>>> the >>>>>>> other end. >>>>>>> >>>>>>> For instance, if a bus is busy, it will return false from its >>>>>>> recvTiming (returning false from the call to sendTiming), and the >>>>>>> sender should then block that port so that no more sends are >>>>>>> attempted. If you look in src/cpu/simple/timing.cc, whenever a >>>>>>> sendTiming fails (for icache or dcache), they enter the >>>>>>> IcacheRetry >>>>>>> or >>>>>>> DcacheRetry state. In this state, no new requests should be >>>>>>> initiated. >>>>>>> >>>>>>> Once the bus is cleared, it will use sendRetry to call >>>>>>> recvRetry on >>>>>>> the sender's port. The sender then tries to send the packet >>>>>>> again. >>>>>>> You >>>>>>> can see this shown in TimingSimpleCPU::IcachePort::recvRetry(). >>>>>>> Note >>>>>>> that the new attempt to send could also fail, which is not an >>>>>>> error. >>>>>>> >>>>>>> As the assertions in that function show, recvRetry should never >>>>>>> be >>>>>>> called unless a previous sendTiming failed. This means that the >>>>>>> receiving side must remember if a port is blocked (and thus needs >>>>>>> to >>>>>>> receive a retry). >>>>>>> >>>>>>> Hope that helps. Others might have more precise details, as well. >>>>>>> >>>>>>> - Clint >>>>>>> >>>>>>> On Dec 15, 2008, at 2:31 PM, Ryan Markley wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I have been studying the code and the tutorial and I have come >>>>>>>> up >>>>>>>> with >>>>>>>> this, and I would like to ask you guys if is right. >>>>>>>> >>>>>>>> When a cpu want to access to the cache sends a petition with >>>>>>>> sendTiming to the port of the cache, and then the cache will >>>>>>>> call >>>>>>>> recvTiming and if the access is successful then perfect and if >>>>>>>> not >>>>>>>> there is no access. Then in the next execution cycle the cpu >>>>>>>> will >>>>>>>> try >>>>>>>> to access again and the cycle repeats until the access is >>>>>>>> successful. >>>>>>>> Is this right?, or those missing accesses are stored somewhere >>>>>>>> and >>>>>>>> there is another policy to management them. >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>> On Wed, Dec 10, 2008 at 8:37 AM, Ryan Markley >>>>>>>> <[email protected]> >>>>>>>> wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Thanks for the link, now the thing is more clear, where is the >>>>>>>>> place >>>>>>>>> in which they are stored?, Are they stored in the retry list >>>>>>>>> that I >>>>>>>>> said in my first mail?. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Dec 10, 2008 at 2:00 AM, Ali Saidi <[email protected]> >>>>>>>>> wrote: >>>>>>>>>> Ryan, >>>>>>>>>> >>>>>>>>>> They are stored back in the bus and then at a later time the >>>>>>>>>> bus >>>>>>>>>> attempts to resend the packet to the cache. Eventually, it >>>>>>>>>> should >>>>>>>>>> accept it. Take a look at: >>>>>>>>>> http://www.m5sim.org/wiki/index.php/Memory_System >>>>>>>>>> >>>>>>>>>> Ali >>>>>>>>>> >>>>>>>>>> On Dec 10, 2008, at 12:21 AM, Ryan Markley wrote: >>>>>>>>>> >>>>>>>>>>> Hello Lisa thanks for your answer, I have checked the code of >>>>>>>>>>> CpuSidePort::recvTiming and I have seen that when the >>>>>>>>>>> petition >>>>>>>>>>> cannot >>>>>>>>>>> be executed the function returns a false, this function is >>>>>>>>>>> called >>>>>>>>>>> for >>>>>>>>>>> the Port, but I do not what happen after when the petition >>>>>>>>>>> cannot >>>>>>>>>>> be >>>>>>>>>>> processed. I imagine that those not successful accesses are >>>>>>>>>>> stored >>>>>>>>>>> somewhere, can you tell me where are those accesses stored?. >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> On Tue, Dec 9, 2008 at 1:42 PM, Lisa Hsu >>>>>>>>>>> <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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 >> > > _______________________________________________ > 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
