|
Dan is right. This is what you are seeing.
Polina
On Thu, Apr 22, 2010 at 9:44 AM, Dan Gibson <degibson@xxxxxxxx> wrote:
Phil (and Byn),
You might be seeing writback events. Those woudn't have an accompanying access from Sequencer associated with them.
Regards,
DanOn Thu, Apr 22, 2010 at 1:35 AM, Byn Choi <bynchoi1@xxxxxxxxxxxx> wrote:
I'm not that familiar with the memory side of things, but I have dealt with the "asynchronous" nature of ruby before and just wanted to chime in with an anecdote to see if it might help in your case.
I had a similar case, basically ruby dying with the message "possible deadlock" due to requests that go unserviced. It's hard to track down where these requests were first issued, because that call stack is lost (that machine state evaporates as soon as the request gets enqueued somewhere). However, as long as you use the *exactly same checkpoint*, you can figure out the first *address* that causes the trouble. Then you simply insert an "if (matches address) { assert(0); }" at the insertion site. By running it again (possibly narrowing down further using cycle count in case that address gets reused a lot) in gdb, you can capture the call stack that lead to inserting the request that later causes the trouble.
It can be a hard labor (which can be made easier using a few clever tricks - including using the cycle count) until actually closing in on the troubling request, but this still gives you a relatively solid path.
Hope this helps,
Byn
On Apr 22, 2010, at 1:56 AM, Philip Garcia wrote:
This might seem like a silly question, but I am adding some code to the memory controller to profile which "cpu" is responsible for each memory access. In doing this, I've added a map of line addresses to cpu numbers in System.C. In the squencer, I have added code that adds an entry to the map when MakeRequest is called, and one to remove entries when hitCallback is called. I have also added code in MemoryControl.C to check this map to query which cpu missed in the cache. However, I am getting multiple memory requests at the memory controller that don't match any entries in the map. I've added code to output what the lineaddress is of every request issued to ruby, and none are even remotely similar to the ones I'm seeing, so it seems unlikely it's an issue of a request wanting multiple lines from the memory.
This makes me wonder if any other structures inside Ruby can accept memory requests, or can generate prefetch requests etc internally. I can't figure out where these requests are coming from, and it's quite frustrating. The requests that miss in the map are relatively rare, but there are still 1000s of them that occur when I just simulate for a few million cycles.
I'm using the MOESI_CMP_directory_m protocol for these tests.
Phil
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site: https://lists.cs.wisc.edu/archive/gems-users/" to your search.
http://www.cs.wisc.edu/~gibson [esc]:wq!
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}