[Gems-users] DNUCA L2_CACHE Hits and Promotions


Date: Tue, 25 Jul 2006 16:28:08 +0200
From: "Daniele Bordes" <daniele.bordes@xxxxxxxxx>
Subject: [Gems-users] DNUCA L2_CACHE Hits and Promotions
Hi all, I am a graduate student and I am working at my
thesis, which is about DNUCA Cache Memories and Gems simulator.

I tried to carry out a trace-driven simulation using
tester.exec, but I don't understand some Ruby output statistics.

I have set L1_cache_assoc = 1  (but L2_cache_assoc is not 1, it's much
greater), and as trace file, I repeat 336 times this sequence of two
references:

5 0x00000001 0 LD
5 0x00900001 0 LD

so I have a total of 672 memory references, all made by the same processor.

(I have created this particular "situation" because I am debugging
tester.exec and ruby and I am trying to understand how really the
simulator works: in this situation, as I explain below, I wanted to
"stimulate" L2_cache to see how insertion, mapping, searching and
block promotions work).


Since L1_cache_assoc = 1, every reference causes a
L1_miss (the two addresses are mapped to the same set), but I expected
670 hits in L2_cache, after the first two cold start misses. But
things go differently.
Well, I really do not manage to understand why the simulator give this
output, in particular the parts concerning L2_Hits:

L1D_cache_total_misses: 672   (this is ok)

DNUCA_promotions_total: 0

DNUCA_allocates_total: 3

DNUCA_L2_hits: 437

DNUCA_read_hits:

readProc 5:
135 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 302 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
     |
[PROCESSOR_5]


L2_cache cache stats:
L2_cache_total_misses: 67


An analog situation appears if I substitute LD operations with
IFETCH operations


I have four questions:

1)  Why are L2_hits only 437?
2)  What happens after a L1_Cache_miss?
3)  What does L2_cache_total_misses parameter mean?
4)  Why there are not blocks promotions after all these hits?

Here there are some ruby configuration parameters I have set before
starting simulation:

protocol: MOESI_CMP_NUCA
g_NUCA_PREDICTOR_CONFIG: DNUCA
ENABLE_MIGRATION: true
ENABLE_REPLICATION: false
g_NETWORK_TOPOLOGY: FILE_SPECIFIED
g_CACHE_DESIGN: NUCACOL

L1_CACHE_ASSOC: 1
L1_CACHE_NUM_SETS_BITS: 9
L2_CACHE_ASSOC: 16
L2_CACHE_NUM_SETS_BITS: 6
g_MEMORY_SIZE_BYTES: 4294967296
g_DATA_BLOCK_BYTES: 64
g_PAGE_SIZE_BYTES: 4096
g_NUM_PROCESSORS: 8
g_NUM_L2_BANKS: 256
g_NUM_MEMORIES: 8
g_PROCS_PER_CHIP: 8
g_NUM_CHIPS: 1
g_NUM_CHIP_BITS: 0
g_MEMORY_SIZE_BITS: 32
g_DATA_BLOCK_BITS: 6
g_PAGE_SIZE_BITS: 12
g_NUM_PROCESSORS_BITS: 3
g_PROCS_PER_CHIP_BITS: 3
g_NUM_L2_BANKS_BITS: 8
g_NUM_L2_BANKS_PER_CHIP_BITS: 8
g_NUM_L2_BANKS_PER_CHIP: 256


Please, could someone help me to solve these doubts?
I am sorry to be a nuisance.
Thank you very much.
[← Prev in Thread] Current Thread [Next in Thread→]