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
