David, I'm not much of a protocol expert, but if you're set on using MSI_MOSI, then you'll have to somehow generate a trace of the coherence actions for whatever block is causing the problem, and figure out why MSI_MOSI doesn't work but MOESI_CMP does. That will be hard, since there isn't any address-specific output.
Look at the *-L2cache.sm files for the two protocols, and see how they handle L2_Replacement actions as a start.
If you're not set on using MSI_MOSI, then by all means just use MOESI_CMP_directory.
Regards,
Dan
PS Its not a problem that m_assoc changes -- that code is common between all caches, so my guess is that you have L1s that are two-way associative.
On Sat, Jun 27, 2009 at 3:11 PM, David Bonavila <david.bonavila@xxxxxxxxxxxxxxxxxx> wrote:
By the way, is it normal that m_assoc keeps changing between 1 and 2 all the time when running simulations with L2_CACHE_ASSOC = 2 ??
I guess it is normal, but I tell you just in case it could help determine the source of my problem.
Regards, David
2009/6/27 David Bonavila <david.bonavila@xxxxxxxxxxxxxxxxxx>
Hi Dan.
I have tried what you said, and now my LRUPolicy.h's getVictim() function is this:
inline
Index LRUPolicy::getVictim(Index set) const { Time time, smallest_time;
Index smallest_index;
smallest_index = 0;
smallest_time = m_last_ref_ptr[set][0];
for (unsigned int i=0; i < m_assoc; i++) {
time = m_last_ref_ptr[set][i];
if (time < smallest_time){
smallest_index = i; smallest_time = time;
} }
printf("m_assoc: %d\n", m_assoc);
if (m_assoc==1) return 0; else return smallest_index;
}
When I run the simulation (using MSI_MOSI_CMP_directory protocol) for 1M instructions it prints "m_assoc: 1" several times, but when it reaches 7139 instructions executed, it exits with no errors or warnings, just like it did before changing getVictim() function.
I have also tried with another protocol (MOESI_CMP_directory) and in this case it seems to work fine, simulating 1M instructions.
So, what might then be the problem??
Thank you!!
Regards,
David
2009/6/25 David Bonavila <david.bonavila@xxxxxxxxxxxxxxxxxx>
Does anyone have any idea of what might be wrong with this ??
Thanks!!
2009/6/11 David Bonavila <david.bonavila@xxxxxxxxxxxxxxxxxx>
Hi,
I'm trying to configure a direct cache (associativity = 1) in Ruby, but I get an strange behavior. This is my script:
read-configuration final-2p.check
magic-break-enable
@conf.con0.input = "cd /parsec/\n";
@conf.con0.input = "./bin/parsecmgmt -a run -i simsmall -x gcc-hooks -p bodytrack -n 2\n";
c
cpu-switch-time 1
instruction-fetch-mode instruction-fetch-trace istc-disable
dstc-disable
load-module ruby
ruby0.setparam g_PROCS_PER_CHIP 2 ruby0.setparam g_NUM_PROCESSORS 2
ruby0.setparam NUMBER_OF_VIRTUAL_NETWORKS 5
ruby0.setparam_str g_REPLACEMENT_POLICY LRU
ruby0.setparam L1_CACHE_ASSOC 1 ruby0.setparam L1_CACHE_NUM_SETS_BITS 8
ruby0.setparam L2_CACHE_ASSOC 1 ruby0.setparam L2_CACHE_NUM_SETS_BITS 12
ruby0.init
load-module opal
opal0.init opal0.sim-start "output_OBJ1-1_BODYTRACK_256KB_ASSOC1.opal"
opal0.sim-step 100000 opal0.stats
ruby0.dump-stats output_OBJ1-1_BODYTRACK_256KB_ASSOC1.ruby q
I read in this mailing list that to configure a direct mapped cache I should set g_REPLACEMENT_POLICY to LRU. I did so, but when I run the script it simulates just 6.000 or 7.000 instructions and the simulation stops. No errors or warnings, all seems correct, but when I look at the stats file just 6 or 7 thousand instructions have been simulated.
If I change "L2_CACHE_ASSOC 1" to "L2_CACHE_ASSOC 2" everything works fine, and I have correctly simulated 20 million instruction with this configuration, even with "L1_CACHE_ASSOC" set to 1. So it's a problem with "L2_CACHE_ASSOC" param which is causing me trouble.
How should I configure a direct L2 cache??
Thank you all!!
_______________________________________________
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!
|