An optimization could be when a processor wishes to take a line from Shared to Modified (when it sends the cache a PrWr), since we already have the latest data (since the line is valid: it's in the Shared state), instead of BusRdX, we just need to broadcast that we have exclusive rights to it and don't need to completely reload it with BusRdX.
This comment was marked helpful 0 times.
kayvonf
@Xelblade: we could write the optimization you describe as PrWr/BusUpgrade. Like BusRdX, BusUpgrade is a transaction where all processors are notified that the issuing processor is taking exclusive access of the line. If differs from BusRdX in that BusRdX also includes the fetch of the cache line from memory. Adding a BusUpgrade operation is a useful optimization on the basic MSI protocol described here.
This comment was marked helpful 0 times.
kayvonf
Question: Why must the cache controller "drop" it's line (transition to the invalid state) when it observes a BusRdX on the interconnect?
This comment was marked helpful 0 times.
sjoyner
Someone intends to change the line, so the current information we have will become invalid in the near future. We don't want to keep reading and writing to outdated data so we drop to the invalid state.
This comment was marked helpful 0 times.
martin
I know someone asked this question in the lecture but I'm still confused about the transition from M to I when the cache observes BusRdX for the line. I understand that the cache needs to drop the line to the invalid state because the data is no longer the most recent one. But why do you need to flush the cache line? Can you simply jump to I state from M and do nothing at all when you observe BusRdX?
This comment was marked helpful 0 times.
TeBoring
@martin I think if you are in M, you probably already has some changes
in your cache, when you need to jump to I. You need to let everyone else know this change.
This comment was marked helpful 0 times.
kayvonf
@sjoyner: Correct. But by "we" you mean "the local processor's cache". And by "someone" you mean a remote processor. And @martin, by "you" you mean "the processor's cache".
Am I being ticky-tack... perhaps, but would these changes make your comments significantly more precise... most certainly.
This comment was marked helpful 0 times.
raphaelk
I think what @martin means is that since some other processor is going to write soon when BusRdX is received, why does the processor bother flushing and write back the currently-modified data to the memory (since it will be overwritten soon?). Can someone clarify this? Or by any chance, is that flush used to "flush" the dirty bits but not necessarily write to the memory?
This comment was marked helpful 0 times.
kayvonf
@raphaelk: The contents of the dirty line must be flushed to memory (or directly communicated to the processor that wants to write to the line) because processor reads and writes can be to individual words or bytes. Just because a processor is going to write to a line it does not mean it will overwrite the entire contents of the line. Consider the case where a 64-byte line X is dirty in processor 1's cache because the processor wrote to word 0 in the line. Now processor 2 wants to write to word 1 in the line. If the word 0 write was not flushed to memory, that write would be lost.
An optimization could be when a processor wishes to take a line from Shared to Modified (when it sends the cache a
PrWr), since we already have the latest data (since the line is valid: it's in the Shared state), instead ofBusRdX, we just need to broadcast that we have exclusive rights to it and don't need to completely reload it withBusRdX.This comment was marked helpful 0 times.
@Xelblade: we could write the optimization you describe as
PrWr/BusUpgrade. LikeBusRdX,BusUpgradeis a transaction where all processors are notified that the issuing processor is taking exclusive access of the line. If differs fromBusRdXin thatBusRdXalso includes the fetch of the cache line from memory. Adding aBusUpgradeoperation is a useful optimization on the basic MSI protocol described here.This comment was marked helpful 0 times.
Question: Why must the cache controller "drop" it's line (transition to the invalid state) when it observes a
BusRdXon the interconnect?This comment was marked helpful 0 times.
Someone intends to change the line, so the current information we have will become invalid in the near future. We don't want to keep reading and writing to outdated data so we drop to the invalid state.
This comment was marked helpful 0 times.
I know someone asked this question in the lecture but I'm still confused about the transition from M to I when the cache observes
BusRdXfor the line. I understand that the cache needs to drop the line to the invalid state because the data is no longer the most recent one. But why do you need to flush the cache line? Can you simply jump to I state from M and do nothing at all when you observeBusRdX?This comment was marked helpful 0 times.
@martin I think if you are in M, you probably already has some changes in your cache, when you need to jump to I. You need to let everyone else know this change.
This comment was marked helpful 0 times.
@sjoyner: Correct. But by "we" you mean "the local processor's cache". And by "someone" you mean a remote processor. And @martin, by "you" you mean "the processor's cache".
Am I being ticky-tack... perhaps, but would these changes make your comments significantly more precise... most certainly.
This comment was marked helpful 0 times.
I think what @martin means is that since some other processor is going to write soon when
BusRdXis received, why does the processor bother flushing and write back the currently-modified data to the memory (since it will be overwritten soon?). Can someone clarify this? Or by any chance, is that flush used to "flush" the dirty bits but not necessarily write to the memory?This comment was marked helpful 0 times.
@raphaelk: The contents of the dirty line must be flushed to memory (or directly communicated to the processor that wants to write to the line) because processor reads and writes can be to individual words or bytes. Just because a processor is going to write to a line it does not mean it will overwrite the entire contents of the line. Consider the case where a 64-byte line X is dirty in processor 1's cache because the processor wrote to word 0 in the line. Now processor 2 wants to write to word 1 in the line. If the word 0 write was not flushed to memory, that write would be lost.
This comment was marked helpful 0 times.