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
