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
