Congradulations. You've posted an article based on false information. Intel's shared L2 cache has been described as a non-inclusive, non-exclusive cache for the specific reason to prevent the problems that AMD is trying to play up. Now how the shared L2 cache operates specifically I'm still not clear on, but it obviously isn't as clear cut as AMD wants you to believe.
Besides, I'm not sure what Apthorpe is talking about anyways. First of all, he makes it sound like you're flushing the entire cache every time you switch programs. As far as I know, the mechanism does not require the flushing of the entire cache but the swapping of the least used cache line in the L2 for incoming data from RAM. This would be true for exclusive or inclusive caches. While the entire cache may be swapped in the end, that only occurs if that is how much new data the processor needs and that is true regardless of of exclusive, inclusive, shared or nonshared caches.
What an inclusive cache really is, is the fact that the contents of the L1 cache is duplicated in the L2. What this means is that when a cache line (again things move in cache lines not the entire cache) needs to be copied from the L2 to the L1, all the L1 needs to do is delete it's copy to make room for new information from the L2. In an exclusive cache, there is no duplication (hence exclusive) which means that when a cache line is copied from the L2 to the L1, the existing L2 cache line needs to first be copied to the L2 before the L1 can except the new cache line from the L2. What this means is that an exclusive cache is actually
slower than an inclusive design not the other way around. There are ways of speeding up an exclusive system such as using a victim buffer.
I bring this up every time I take about cache architecture, so once again I'll mention that an exclusive design like what AMD uses relies on the L1 cache more than the L2. That is why we see AMD using larger L1 caches than Intel. By the same token, an inclusive cache design benefits more from the L2 which is why Intel uses larger L2 caches. It's not that AMD doesn't benefit from larger L2 caches, its just that relatively they'd benefit less. AMD plays it off that their architecture doesn't require large L2 caches which is true, because even if they increase the L2, they hit the point of diminishing returns a lot quicker so it isn't worth it for them to have large L2 caches. Intel uses large L2 caches to gain a 2-fold benefit, the fact that inclusive caches gain more from large L2 caches, and the fact that large L2 caches alleviate any FSB bottleneck.
Moving on to cache trashing, that issue has been played up far too much. Cache trashing was an issue in Netburst processors with HT, because the cache had no control over allocation to each core which meant one core could be evicting a cache line that another core needs, and one core could theoretically monopolize the entire cache. That isn't the case with the "smart" shared L2 cache in Conroe. The prefetchers and other logic in the cache dynamically allocated cache to each core based on their usage patterns and projected needs. This means that it isn't possible for one core to completely take over the cache if the 2nd core needs cache space too. Now it's possible that the dynamic sharing mechanism isn't fool proof, but you shouldn't assume that it doesn't exist.
Finally,
Is this the reason why the Woodcrest/Coroe are prone to cache trashing?
Really, where? I'd love to see a link that conclusively proves cache trashing. You'd probably want to wait for the shipping products anyways since the last CPU revisions could tweak things, and newer BIOS would improve memory handling. (For a note, even though GamePC used stepping 5 for Woodcrest which is probably the shipping version, the CPU themselves were still labelled Engineering Samples. The Woodcrests that THG has right now are even older stepping 4 Engineering Samples).
Is this the main reason why AMD is going for a large and shared L3 cache?
I wouldn't call a 2MB shared L3 cache large, especially between 4 cores. If you want a large shared L3 cache you'd look to Tulsa with it's 16MB shared L3 cache for 2 cores. Even with sharing done in L3 instead of L2, with each dedicated L2 only being 512k you'd still be relying on properly working dynamic sharing mechanisms in the L3 cache, because the 512k L2 won't keep the core fed for long, especially if K8L has the vast performance potential that you believe.
Facebook
Twitter
Instagram