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.
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}