| I don't know the exact reasoning behind the code (I do not work on the multifacet project, I've just used GEMS extensively), however I remember when I looked at the code, I compared the isReady method to one from an earlier version of GEMS that is available (a pre SMT version). In that one, the invariant wasn't there (as Luke had added the code for SMT later). In that version, Ruby's code checked that only one read or one write was outstanding to the same cache line, but both a read and a write could be outstanding at the same time. In honesty, I don't know enough about how cache controllers and LSQs handle things like two requests to the same cache line, so I can't say what is the "proper" way to do things. Is your problem that you're issuing a read and another read to the same line is outstanding?
It does seem odd to me that FeS2 would have an assertion around isReady, as isReady should be called for every memory access. There are multiple conditions in which isReady will fail. the first is when multiple requests to the same line are out, and the second is when there are too many requests queued up in the cache port (this can be set by a global variable that I forget offhand, but it's pretty easy to find). These conditions can happen. One thing you might want to check if it's a problem with two requests to the same cache line is that ruby and FeS2 know the cache line size. I assume FeS2 models an LSQ internally, so that would need to be aware of ruby's cache line size. Does FeS2 call isReady anywhere else in the code besides that assertion? It seems to me like a bug in FeS2 if they assume the cache should always be ready, but you might want to ask them about how it's supposed to operate.
Phil On Mar 31, 2011, at 6:13 PM, Binh Q. Pham wrote:
Hi Phil,
Thanks for a quick response. I was using FeS2 + ruby. FeS2 is a
timing simulator for X86, and in the port, it replaced opal's role.
Below is the crash error I got while running a test benchmark on
FeS2 + ruby.
Event Log:
SWITCH TO TIMING
simics-common: pyrite/RubyMemoryInterface.cpp:69: virtual void
RubyMemoryInterface::request(int, Waddr, Waddr, int, RequestType,
Waddr, int, int, Waiter*): Assertion
`(*g_ruby_api->isReady)(cpuNumber, logicalAddr, physicalAddr,
((type==REQUEST_READ)?OPAL_LOAD:OPAL_STORE), thread)' failed.
Abort (SIGABRT) in main thread
The simulation state has been corrupted. Simulation cannot
continue.
Please restart Simics.
Basically, g_ruby_api is linked to opal-interface in FeS2:
g_ruby_api = g_ruby_api = (mf_ruby_api_t*) SIM_get_interface(ruby,
"mf-ruby-api");
opal_interface = MM_ZALLOC(1, mf_ruby_api_t);
SIM_register_interface(ruby_class, "mf-ruby-api", opal_interface);
init_opal_interface( opal_interface );
The backtrace calls that lead to the error above is as following:
1. When a load/store instruction gets executed, FeS2 makes a call to
cacheAccess().
2. Inside that function cacheAccess(), RubyMemoryInterface::request
is called.
3. Inside RubyMemoryInterface::request,
assert((*g_ruby_api->isReady)(cpuNumber, logicalAddr,
physicalAddr, ((type==REQUEST_READ)?OPAL_LOAD:OPAL_STORE), thread))
is called
4. Inside *g_ruby_api->isReady, Sequencer::isReady is called
--> it returns false because for some reason, there is more than
one outstanding request for the current address. As a result, the
assert statement mentioned in step 3 failed, and the whole
simulation crashed!
Currently, I temporarily commented that code out, and the simulation
went through without being crashed. However, I am afraid I would be
missing something fundamental here. Therefore, I would like to know
the reason why there is such restriction about the number of
requests per address.
Thanks again for your time and help,
Binh
On 03/31/2011 06:42 PM, Philip Garcia wrote:
Do you know what the crash is? I recently experienced
some issues with the isReady code when using an SMT setup where I
could end up in a case were one of the SMT threads starves the
other, and a lack of forward progress is made. However, this was
for GEMS with ruby/opal loaded. If you could give details of the
system you were simulating, and what the error was I might be able
to offer some advice on it.
I'm not 100% sure about the invariant thrown in there either,
I didn't end up changing that at all.
Phil
On Mar 31, 2011, at 3:14 PM, Binh Q. Pham wrote:
Hi everyone,
I am using GEMS for x86, and my simulation crashed in
Sequencer::isReady:
// LUKE - disallow more than one request type per
address
// INVARIANT: at most one request type per
address, per processor
int smt_threads = RubyConfig::numberofSMTThreads();
for(int p=0; p < smt_threads; ++p){
if(
m_writeRequestTable_ptr[p]->exist(line_address(request.getAddress()))
||
m_readRequestTable_ptr[p]->exist(line_address(request.getAddress()))
){
cout << "OUTSTANDING REQUEST EXISTS "
<< p << " VER " << m_version <<
endl; //binh: bug is here
//printProgress(cout);
return false;
}
}
Is there any reason why we have to keep the invariant: one
request type per address above? To me, it is possible to
have multiple requests per address in the cache...
Thank you in advance for your time and help,
Binh
_______________________________________________
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.
|
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}