Date: | Thu, 8 Apr 2010 11:50:18 -0500 |
---|---|
From: | Dan Gibson <degibson@xxxxxxxx> |
Subject: | Re: [Gems-users] L2 Miss Profiling |
Ahh, ocean. If only I had a dollar for every time I've seen this same issue with ocean. Here is what is going on: 258x258 elements * 4 bytes/integer * 2 copies of the ocean (because of shadowing) = 520 KB working set size. Aggregate L1 cache size = 64KB * 16 Processors = 1MB. Aggregate L2 cache size = 1MB. In other words, after the first full timestep, the entire ocean is resident in the L1 caches. Any misses from the L1s at that point are sharing misses, which 'miss' in the L2 because other L1s must be invalidated. Also, for this particular case, the L2 is no bigger than the aggregation of the L1s. I would hope that the L2 isn't inclusive, but I honestly don't know if it is or not for MESI_CMP_filter_directory. If it IS inclusive, obviously an L2 hit would only happen rarely, on a transient condition. Regards, Dan On Thu, Apr 8, 2010 at 11:44 AM, Nilay Vaish <nilay@xxxxxxxxxxx> wrote:
-- http://www.cs.wisc.edu/~gibson [esc]:wq! |
[← Prev in Thread] | Current Thread | [Next in Thread→] |
---|---|---|
|
Previous by Date: | Re: [Gems-users] L2 Miss Profiling, Nilay Vaish |
---|---|
Next by Date: | [Gems-users] Ruby and Opal Compile error (searched mail list already), Michael Zhen WANG |
Previous by Thread: | Re: [Gems-users] L2 Miss Profiling, Nilay Vaish |
Next by Thread: | Re: [Gems-users] L2 Miss Profiling, Nilay Vaish |
Indexes: | [Date] [Thread] |