Re: [Gems-users] Problems configuring direct cache in Ruby...

[David Bonavila <david.bonavila@xxxxxxxxxxxxxxxxxx>]

Thank you for your reply Dan. I have just re-posted my question with a new subject.
I hope someone can help me, because debugging and fixing this issue is far too complicated for me and I don't have enough time to deal with it.

Best regards
David


-----------------------------------------------------
David,

On Sun, Jun 28, 2009 at 6:43 PM, David Bonavila <david.bonavila@xxxxxxxxxxxxxxxxxx> wrote:

> My L1 caches are always direct (assoc = 1), and m_assoc keeps changing between 1 and 2 when using a 2-way L2.
> Might that have something to do with my direct L2 cache problem??

As long as you have a cache somewhere in the system with assoc=2, I would expect for prints of m_assoc to occasionally print '2'. CacheMemory.[Ch] is code common to all caches.
 

> It's
> not that I'm set on using MSI_MOSI, but I have run quite a lot of
> simulations with MSI_MOSI (2 and 4-way associativity) and to compare
> results with direct cache I should use the same protocol, because
> comparing direct cache using MOESI with 2 and 4-way cache using
> MSI_MOSI doesn't make much sense, does it?

I see your motivation now. However, obviously there is something about MSI_MOSI that does not work with assoc=1, which means that if you want to evaluate a direct-mapped cache you will have to debug and fix (modify) the protocol. Albeit, a fixed protocol is more of an apples-to-apples comparison than a different protocol.

Aside: As far as making further progress on this point, I recommend you re-post your question to gems-users with a subject like 'MSI_MOSI direct-mapped cache', in order to garner attention from fellow gems-users who are familiar with that protocol.
 

> Is it possible that I need to set some other parameters like
> num_blocks, num_memories, or something like that in order to model a
> direct cache?? I don't think so, because using MOESI protocol I didn't
> set any extra parameters and it seemed to work just fine.

It certainly wouldn't hurt to experiment with these. In theory, SLICC is supposed to be mostly independent of the number of blocks and memories -- but in practice, its not.
 

> By the way, I tried the MOESI protocol BEFORE changing getVictim()
> function. So with the default getVictim() function MOESI protocol seems
> to work fine, and MSI_MOSI protocol is not working fine neither with
> the default function or with the new function.

My suggestion to change getVictim() was a shot in
the dark -- if there had been a problem with getVictim() (and I do not
think there was), then it would have been a simple and trivial fix.
However, we didn't get lucky -- I don't think it would do any good to
try your new getVictim() with MOESI_CMP.

Regards,
Dan

2009/6/29 David Bonavila <david.bonavila@xxxxxxxxxxxxxxxxxx>

Hi Dan, thank you for your answer.

My L1 caches are always direct (assoc = 1), and m_assoc keeps changing between 1 and 2 when using a 2-way L2.
Might that have something to do with my direct L2 cache problem??

It's not that I'm set on using MSI_MOSI, but I have run quite a lot of simulations with MSI_MOSI (2 and 4-way associativity) and to compare results with direct cache I should use the same protocol, because comparing direct cache using MOESI with 2 and 4-way cache using MSI_MOSI doesn't make much sense, does it?

Is it possible that I need to set some other parameters like num_blocks, num_memories, or something like that in order to model a direct cache?? I don't think so, because using MOESI protocol I didn't set any extra parameters and it seemed to work just fine.

By the way, I tried the MOESI protocol BEFORE changing getVictim() function. So with the default getVictim() function MOESI protocol seems to work fine, and MSI_MOSI protocol is not working fine neither with the default function or with the new function.


Thank you!!
Best regards,

David

2009/6/27 David Bonavila <david.bonavila@xxxxxxxxxxxxxxxxxx>

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!!