Daniele,
First of all, let me reiterate that I know almost nothing at all about
the NUCA protocols. I'm responding now because the chief author of the
NUCA protocols is currently rather busy with a dissertation, so I
apologize in advance if I'm a bit vague.
Are you sure the allocation into the L2 of 0x000000C0 is due to the
third reference, and not the fifth? Could the L2 allocation of 0x0C0 be
due to its second reference?
My intuition of the sequence you're running suggests that references
1-3 (to 0x040, 0x080, and 0x0C0) will be cached in the L1. 0x00900040
will evict 0x040, and replace it in the L1 cache. This assumes a
reasonably large number of entries in the direct-mapped L1.
If the L1 size is very small (eg two entries), the 0x0C0 reference will
be evicted by 0x00900040 -- could you be observing a victim caching
effect perhaps? I'm not sure if CMP_NUCA implements victim replacment to
the L2, but I know of some protocols that do so.
Regards,
Dan
Daniele Bordes wrote:
Hi Dan, thank you very much for your answer. Well, I have changed only
the second call to triggerEvents() to triggerAllEvents() in
void TraceRecord::issueRequest(), so now I expect that each reference
is processed completely before the next one. But debugging tester.exec
and ruby with this trace file (all references are made by the same
processor, and L1 cache associativity is set to 1):
0x00000040 LD
0x00000080 LD
0x000000C0 LD
0x00900040 LD
0x000000C0 LD
0x00900040 LD
I have noted that the block 0x000000C0 (third reference) is allocated
in L2 cache ONLY after the reference 0x00900040 (fourth reference) is
read from the trace file. Do you know what's going on?
Sorry to be a nuisance.
_______________________________________________
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]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}