1. Performance of the Shasta distributed shared memory protocol Daniel J. Scales Kourosh Gharachorloo 創造情報学専攻 M1 076602. グェン トアン ドゥク

2. Agenda Basic design of Shasta Protocol optimizations Performance result

3. Basic design of Shasta

4. Cache coherent protocol 3 states: invalid, shared, exclusive Shared miss: (invalid) read, (invalid/shared) write Block size can be different for different ranges of shared address space Address space is divided into fixed-size ranges, call lines –Block = n * lines Maintain state information for each line in state table

5. Basic shared miss check

6. Shared miss check optimizations Invalid flag technique: –Set invalid line’s long word (4 byte) value = Special flag value –Compare word value with flag value -> miss or not Batching miss checks –Batch together checks for multiple loads / stores

7. Protocol optimizations Minimizing protocol messages –Owner node guarantees to service request forwarded to it –No need retry request due to transient states or deadlock: save request into queue Multiple coherence granularity –Block size based on data structure Small object: single unit Large object: divide into lines –Associate different granularities to different virtual pages

8. Protocol optimizations (2) Exploiting relaxed memory model –Non-blocking load / store –Non-blocking release –Eager exclusive replies Read exclusive: sending data back immediately to the requested processor, delay request from other processors Batching Detecting migratory shared patterns –Migratory sharing: data is read and modified by different processors -> migration from one processor to another

9. Performance

10. Effect of Release Consistency Non blocking release

11. Effect of upgrade & sharing writeback Support for upgrade messages is important for some application (VolRend) Sharing writeback messages hurt performance

12. Effect of migratory optimization Disappointing!

13. Summary of results Support for variable granularity communication is the most important optimization in Shasta Support for upgrade messages and a dirty- sharing protocol are also important Exploiting RC provides small performance gains because processors are busing handling protocol messages while they are waiting for their own request to complete Migratory optimization is not useful in Shasta

14. Conclusion Shasta supports fine-grain access to shared memory by inserting code before load / store instructions to check state of the shared data Shasta supports shared memory entirely in software -> flexibility in granularity & optimizations Variable granularity is the most important optimization