| |
MOESI protocol
- State transitions pertaining to O state
- I to O: not possible
- E to O or S to O: not possible
- M to O: on a BusRd/Flush (but no memory writeback)
- O to I: on CacheEvict/BusWB or {BusRdX,BusUpgr}/Flush
- O to S: not possible
- O to E: not possible
- O to M: on PrWr/BusUpgr
- At most one cache can have a line in O state at any point in time
- Two main design choices for MOESI
- Consider the example: P0 reads x, P0 writes x, P1 reads x, P2 reads x, P3 reads x, …
- When P1 launches BusRd, P0 sources the line and now the protocol has two options: 1. The line in P0 goes to O and the line in P1 is filled in state S; 2. The line in P0 goes to S and the line in P1 is filled in state O i.e. P1 inherits ownership from P0
- For distributed shared memory, the second choice is better
- According to the second choice, when P2 generates a BusRd request, P1 sources the line and transitions from O to S; P2 becomes the new owner
- Some SMPs do not support the E state
- In many cases it is not helpful, only complicates the protocol
- MOSI allows a compact state encoding in 2 bits
- Sun WildFire uses MOSI protocol
Hybrid inval+update
- One possible hybrid protocol
- Keep a counter per cache line and make Dragon update protocol the default
- Every time the local processor accesses a cache line set its counter to some pre-defined threshold k
- On each received update decrease the counter by one
- When the counter reaches zero, the line is locally invalidated hoping that eventually the writer will switch to M state from Sm state when no sharers are left
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|
|
|
|
