The one part of the cache hierarchy that did not appear to change much from a high-level view is hurting BD. However, it looks like there are problems with the shared module cache architecture when it comes to write combining, so maybe it's just a constant.
The write combining problem looks like a bug since a revision is coming to fix it.
I don't know how to describe the problem with the cross-invalidation problem.
AMD stuck with a big low-associativity cache and then they ran two threads through it.
By way of comparison, SB's Icache is half the size and four times the associativity (takes three bits out of the index), which I assume is why it doesn't need something like this.
AMD must, or should have, have seen this coming. Did they think it was an acceptable trade-off? Did they think the cost would be lower? It's a few percent off overall. Going by the comments by Linus Torvalds and other about this fix for Linux, there is some cosmic irony that this server architecture slightly compromises the level of security because it keeps the affected parts of the virtual address from being randomized.
The write combining problem looks like a bug since a revision is coming to fix it.
I don't know how to describe the problem with the cross-invalidation problem.
AMD stuck with a big low-associativity cache and then they ran two threads through it.
By way of comparison, SB's Icache is half the size and four times the associativity (takes three bits out of the index), which I assume is why it doesn't need something like this.
AMD must, or should have, have seen this coming. Did they think it was an acceptable trade-off? Did they think the cost would be lower? It's a few percent off overall. Going by the comments by Linus Torvalds and other about this fix for Linux, there is some cosmic irony that this server architecture slightly compromises the level of security because it keeps the affected parts of the virtual address from being randomized.