Daniele,
This is sounding more and more like a victim allocation. I don't know
what rules in inclusivity/exclusivity the NUCA protocol is supposed to
follow, but here is my thought:
0x00000040 LD Issue: Compulsory miss in L1, Compulsory miss in L2,
Allocate in L1 and L2.
0x00000080 LD Issue: Compulsory miss in L1, Compulsory miss in L2,
Allocate in L1 and L2.
0x000000C0 LD Issue: Compulsory (conflicts if L1 is very small) in L1, Compulsory miss in the L2,
Allocate in L1 only (for a reason I'm not clear on, probably because I do
not know the protocol well -- it could even be a heuristic)
0x009000C0 LD Issue: Compulsory miss in L1/L2, conflicts with 0x0C0
Allocate in L1 (victimize 0x0C0)
Allocate 0x0C0 in L2 (victimization policy)
That is, I think you are observing the intended behaviour of the
protocol...you might try grepping the source for use of random number
heuristics or have alook at the allocation policy or L1 eviction policy
to figure out what is going on.
Regards,
Dan
Daniele Bordes wrote:
Hi Dan. Frist of all, excuse me, but the trace file I wrote last time
was wrong; this is the correct trace file:
0x00000040 LD
0x00000080 LD
0x000000C0 LD
0x009000C0 LD
0x000000C0 LD
0x009000C0 LD
(Last time I was wrong, having confused 009000C0 with 00900040)
Well, I am nearly sure the allocation in L2 of 0x000000C0 is due to
the third reference. Here there is the sequence of the first ten
"events" (that is, function calls) among issuing an address and
allocating it:
0x00000040 issue
0x00000040 allocated in L1
0x00000040 allocated in L2
0x00000080 issue
0x00000080 allocated in L1
0x00000080 allocated in L2
0x000000C0 issue
0x000000C0 allocated in L1
0x009000C0 issue
0x009000C0 allocated in L1
0x000000C0 allocated in L2
As you can see, it seems that the allocation of 0x000000C0 in L2
happens AFTER 0x009000C0 issue, but it is different from how the trace
file is organized; well, it seems to me very strange, because I made
some code modifications (for instance, triggerAllEvents before
processing a new reference) that I believe would have forced simulator
to completely perform all the actions due to an address reference
before issuing the next one. Perhaps, the allocation in L2 of
0x000000C0 is not due to the Load, but to the eviction in L1 of that
address just after 0x009000C0 allocation in L1 (remember that L1
associativity is 1), but should not the memory hierarachy be strictly
inclusive? And if not, why 0x000000C0 is not allocated in L2 but the
two previous addresses are allocated in L2?
Is there something wrong in my reasoning? Please, can you help me?
Sorry to be a nuisance.
Thank you very much.
_______________________________________________
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.
|