As far as I understand, that has not much changed between GEMS and gem5
(beyond some structural changes). But knowledge of GEMS should be enough
in gem5 to figure that out easily.
More specifically, to find out L1/L2/L3 hit/miss etc., you need to put
your profiling functions from the protocol description files (.sm). Note
that the cache hierarchy, along with the coherence is simulated by the
SLICC generated code.
Arka
On 07/31/2011 10:07 AM, Carole-Jean Wu wrote:
Hi Arka,
Thanks for the explanation. This I understand...
Where should I look into if I want to i.e. know where cache hit/miss happens
and how victims are selected etc.? It was clear in GEMS but I cannot find
these codes are in gem5.
Thanks,
Carole
On Sun, Jul 31, 2011 at 10:46 AM, Arkaprava Basu<[email protected]> wrote:
Hi Carole,
tryCacheAccess is not used in normal case. It was more kind of backdoor to
figure out whether there will be a hit in L1 cache.I guess current version
even comment that out.
To find out how the request re handled in Cache hierarchy simulated by
Ruby, start by looking into Sequencer::makeRequest(), which then calls
Sequencer::issueRequest(). These functions do some checking and then creates
a RubyRequest messages (which is understood by the SLICC generated cache
hierarchy of Ruby). Finally it pushes the request to the cache hierarchy by
calling m_mandatory_q_ptr->enqueue(**msg, latency); at the end of the
Sequencer::issueRequest() function. The "mandatory queue"s are attached to
the L1 Cache controller of the SLICC simulated cache hierarchy. The cache
hierarchy along with the coherence protocol (SLICC generated code) will
simulate the request after de-queuing the request from the mandatory queue
at the L1 cache controller.
Arka
On 07/30/2011 08:22 PM, Carole-Jean Wu wrote:
Hi,
I am trying to reason about the printed ruby statistics in the default
ruby.stats by comparing it with my own miss counter implementation. From
my
understanding, all memory requests will be sent to system/Sequencer.cc and
to access the cache, it has to call tryCacheAccess. However, this function
doesn't seem to be called at all in my simulation. Am I looking at the
wrong
function? Can someone point out the **cache access** function for all
memory
requests?
thanks in advance,
Carole
______________________________**_________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/**mailman/listinfo/gem5-users<http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>
______________________________**_________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/**mailman/listinfo/gem5-users<http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
