In class we discussed what would happen if while processor 1 is waiting to receive address A's data from memory after issuing a BusRdx, processor 2 wants to issue a BusRdx to addr A.
Kayvon said that in that case, processor 2 would withhold its BusRdx request until processor 1 got the data from memory. This seems to have several implications:
1) caches need to snoop not only memory requests from other caches but also the data that is being received by other caches from memory, and in the case where a processor is withholding a BusRdx, it must monitor the address bus of all data being sent from memory to other processors to see if any of those address matches up with the address that it is withholding a BusRdx for.
2) The way a cache manages its request queue for the bus gets a bit more complicated. Where does a request for a BusRdx go if the cache realizes it must withhold its BusRdx till a later time? All the way back to the end of the queue? This seems costly in terms of latency. If the program cannot progress until it receives the response for the BusRdx, it has to wait for the entire length of the queue to continue to do work.
iZac
To make it more elaborate, we could add following at the start:
Fetch instruction from PC
Decode instructions (get uops if x86)
Store to write buffer
Wait for ROB (re-order buffer) to tell if its the one to be committed next
(Then begin process to get data and modify as mentioned)
Virtual address to physical address conversion ...
kayvonf
@iZac. Decode instruction could be fairly complex as well. ;-) Question for those that want to go deeper. What is a uop cache?
iZac
Instructions in x86 after decode are converted into several basic instructions called uops. This sequence of uops control the CPU at a very fundamental level of hardware circuitry. These uop sequences generated can be cached in a special structure called uop cache. Doing so enables reduction in the processor's power and energy consumption while not compromising performance.
In class we discussed what would happen if while processor 1 is waiting to receive address A's data from memory after issuing a BusRdx, processor 2 wants to issue a BusRdx to addr A. Kayvon said that in that case, processor 2 would withhold its BusRdx request until processor 1 got the data from memory. This seems to have several implications:
1) caches need to snoop not only memory requests from other caches but also the data that is being received by other caches from memory, and in the case where a processor is withholding a BusRdx, it must monitor the address bus of all data being sent from memory to other processors to see if any of those address matches up with the address that it is withholding a BusRdx for.
2) The way a cache manages its request queue for the bus gets a bit more complicated. Where does a request for a BusRdx go if the cache realizes it must withhold its BusRdx till a later time? All the way back to the end of the queue? This seems costly in terms of latency. If the program cannot progress until it receives the response for the BusRdx, it has to wait for the entire length of the queue to continue to do work.
To make it more elaborate, we could add following at the start:
(Then begin process to get data and modify as mentioned)
Virtual address to physical address conversion ...
@iZac. Decode instruction could be fairly complex as well. ;-) Question for those that want to go deeper. What is a uop cache?
Instructions in x86 after decode are converted into several basic instructions called uops. This sequence of uops control the CPU at a very fundamental level of hardware circuitry. These uop sequences generated can be cached in a special structure called uop cache. Doing so enables reduction in the processor's power and energy consumption while not compromising performance.