Hello again, and sorry for the multiple questions, I hope that this also will be helpful for somebody else in the future:
As I said in one of my previous mail I am capturing the packages in the bus.cc file, basically what I do is in the function recvTiming, I have several variables and in those variables I store the petitions from the different sources, the code is working and I see using the bus flag how my variables increase according to the different petitions from the sources. But the problem is after, when I go to the stats generated by the simulator the numbers are not the same, for example I think that for the different accesses generated by the simulator dcache.ReadReq_accesses, dcache.WriteReq_accesses ..., some number needs to be the same than the ones that I am getting, but no, any reason for this?. Thank you. On Tue, Dec 16, 2008 at 5:08 PM, Ryan Markley <[email protected]> wrote: > 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
