Re: [Gems-users] Strange Ruby statistics

[Dan Gibson <degibson@xxxxxxxx>]

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