From the high level summary of the caching model, it would be undesirable for the L2 to have a line populated and accessible before the L3 and its coherence/snoop information is populated with a state consistent with the L2's status and core-use information.
The L2 prefetcher's fetches create an L2 miss, which I think a more straightforward implementation would then go the L3 to see if the data is there.
If not there, then the L3 slice could generate an L3 miss that would then send a request to memory or broadcast a request if it is an SMP setup.
The listed behavior would readily fall out of this chain if the sequence is maintained, and the rule is that the prefetcher's miss can be discarded and the L3 slice's miss cannot.
I'm not sure if that means a message or signal is sent out to actively cancel the L2's request or the L2 makes a note of ignoring or rejecting it. Ignoring it might work since Intel's level of inclusion is not total, and the cores can silently evict lines without telling the L3. This would be like a preemptive eviction of a line. At worst, that leads to redundant snoops or invalidates that yield nothing.
That might not be what the hardware necessarily does. There are events separated by variable amounts of time, and it may be possible to shift events around or bypass stages as long as the arbitrating hardware properly isolates intermediate states or recovers from problems. For Intel's inclusive L3, the slices each have agents that manage that arbitration, so it would seem like the L3 would be the nearest place to update when the caching agent starts processing the transaction.
I'm not sure if any of the mentions yesterday were meant to have gone through or if mentions don't archive, since my list doesn't seem to have any from this thread.
Last edited:
