SlideShare a Scribd company logo
1 of 20
1
Directory Protocols
• Topics: directory-based cache coherence implementations
2
Flat Memory-Based Directories
Main memory
Cache 1 Cache 2 Cache 64
…
…
Block size = 128 B
Memory in each node = 1 GB
Cache in each node = 1 MB
For 64 nodes and 64-bit directory,
Directory size = 4 GB
For 64 nodes and 12-bit directory,
Directory size = 0.75 GB
3
Flat Memory-Based Directories
L2 cache
L1 Cache 1 L1 Cache 2 L1 Cache 64
…
…
Block size = 64 B
L2 cache in each node = 1 MB
L1 Cache in each node = 64 KB
For 64 nodes and 64-bit directory,
Directory size = 8 MB
For 64 nodes and 12-bit directory,
Directory size = 1.5 MB
4
Flat Cache-Based Directories
Main memory…
Block size = 128 B
Memory in each node = 1 GB
Cache in each node = 1 MB
6-bit storage in DRAM for each block;
DRAM overhead = 0.375 GB
12-bit storage in SRAM for each block;
SRAM overhead = 0.75 MB
Cache 7 Cache 3 Cache 26
5
Flat Cache-Based Directories
Main memory…
6-bit storage in L2 for each block;
L2 overhead = 0.75 MB
12-bit storage in L1 for each block;
L1 overhead = 96 KB
Cache 7 Cache 3 Cache 26
Block size = 64 B
L2 cache in each node = 1 MB
L1 Cache in each node = 64 KB
6
Flat Cache-Based Directories
• The directory at the memory home node only stores a
pointer to the first cached copy – the caches store
pointers to the next and previous sharers (a doubly linked
list)
• Potentially lower storage, no bottleneck for network traffic,
• Invalidates are now serialized (takes longer to acquire
exclusive access), replacements must update linked list,
must handle race conditions while updating list
7
Serializing Writes for Coherence
• Potential problems: updates may be re-ordered by the
network; General solution: do not start the next write until
the previous one has completed
• Strategies for buffering writes:
 buffer at home: requires more storage at home node
 buffer at requestors: the request is forwarded to the
previous requestor and a linked list is formed
 NACK and retry: the home node nacks all requests
until the outstanding request has completed
8
SGI Origin 2000
• Flat memory-based directory protocol
• Uses a bit vector directory representation
• Two processors per node, but there is no snooping
protocol within a node – combining multiple processors
in a node reduces cost
P
L2
CA
M/D
P
L2
Interconnect
9
Protocol States
• Each memory block has seven states
• Three stable states: unowned, shared, exclusive (either
dirty or clean)
• Three busy states indicate that the home has not
completed the previous request for that block
(read, read-excl or upgrade, uncached read)
• Poison state – used for lazy TLB shootdown
10
Handling Reads
• When the home receives a read request, it looks up
memory (speculative read) and directory in parallel
• Actions taken for each directory state:
 shared or unowned: memory copy is clean, data
is returned to requestor, state is changed to excl if
there are no other sharers
 busy: a NACK is sent to the requestor
 exclusive: home is not the owner, request is fwded
to owner, owner sends data to requestor and home
11
Inner Details of Handling the Read
• The block is in exclusive state – memory may or may not
have a clean copy – it is speculatively read anyway
• The directory state is set to busy-exclusive and the
presence vector is updated
• In addition to fwding the request to the owner, the memory
copy is speculatively forwarded to the requestor
 Case 1: excl-dirty: owner sends block to requestor
and home, the speculatively sent data is over-written
 Case 2: excl-clean: owner sends an ack (without data)
to requestor and home, requestor waits for this ack
before it moves on with speculatively sent data
12
Inner Details II
• Why did we send the block speculatively to the requestor
if it does not save traffic or latency?
 the R10K cache controller is programmed to not
respond with data if it has a block in excl-clean state
 when an excl-clean block is replaced from the cache,
the directory need not be updated – hence, directory
cannot rely on the owner to provide data and
speculatively provides data on its own
13
Handling Write Requests
• The home node must invalidate all sharers and all
invalidations must be acked (to the requestor), the
requestor is informed of the number of invalidates to expect
• Actions taken for each state:
 shared: invalidates are sent, state is changed to
excl, data and num-sharers is sent to requestor,
the requestor cannot continue until it receives all acks
(Note: the directory does not maintain busy state,
subsequent requests will be fwded to new owner
and they must be buffered until the previous write
has completed)
14
Handling Writes II
• Actions taken for each state:
 unowned: if the request was an upgrade and not a
read-exclusive, is there a problem?
 exclusive: is there a problem if the request was an
upgrade? In case of a read-exclusive: directory is
set to busy, speculative reply is sent to requestor,
invalidate is sent to owner, owner sends data to
requestor (if dirty), and a “transfer of ownership”
message (no data) to home to change out of busy
 busy: the request is NACKed and the requestor
must try again
15
Handling Write-Back
• When a dirty block is replaced, a writeback is generated
and the home sends back an ack
• Can the directory state be shared when a writeback is
received by the directory?
• Actions taken for each directory state:
 exclusive: change directory state to unowned and
send an ack
 busy: a request and the writeback have crossed
paths: the writeback changes directory state to
shared or excl (depending on the busy state),
memory is updated, and home sends data to
requestor, the intervention request is dropped
16
Serialization
• Note that the directory serializes writes to a location, but
does not know when a write/read has completed at any
processor
• For example, a read reply may be floating on the network
and may reach the requestor much later – in the meantime,
the directory has already issued a number of invalidates,
the invalidate is overwritten when the read reply finally
shows up – hence, each node must buffer its requests
until outstanding requests have completed
17
Serialization - II
• Assume that a dirty block is being passed from P1 to
another writer P2, the “ownership transfer” message from
P1 to home takes a long time, P2 receives its data and
carries on, P2 does a writeback  protocol must be
designed to handle this case correctly
If the writeback is from the node that placed the directory
in busy state, the writeback is NACKed
(If instead, the writeback was allowed to proceed, at
some later point, if the directory was expecting an
“ownership transfer”, it may mis-interpret the “floating”
message)
18
Directory Structure
• The system supports either a 16-bit or 64-bit directory
(fixed cost)
• For small systems, the directory works as a full bit
vector representation
• For larger systems, a coarse vector is employed – each
bit represents p/64 nodes
• State is maintained for each node, not each processor –
the communication assist broadcasts requests to both
processors
19
Page Migration
• Each page in memory has an array of counters to detect
if a page has more misses from a node other than home
• When a page is moved to a different physical memory
location, the virtual address remains the same, but the
page table and TLBs must be updated
• To reduce the cost of TLB shootdown, the old page sets
its directory state to poisoned – if a process tries to access
this page, the OS intervenes and updates the translation
20
Title
• Bullet

More Related Content

What's hot

Exchang Server 2013 chapter 2
Exchang Server 2013 chapter 2Exchang Server 2013 chapter 2
Exchang Server 2013 chapter 2Osama Mohammed
 
RocksDB compaction
RocksDB compactionRocksDB compaction
RocksDB compactionMIJIN AN
 
Plugging in oracle database 12c pluggable databases
Plugging in   oracle database 12c pluggable databasesPlugging in   oracle database 12c pluggable databases
Plugging in oracle database 12c pluggable databasesKellyn Pot'Vin-Gorman
 
Pgxc scalability pg_open2012
Pgxc scalability pg_open2012Pgxc scalability pg_open2012
Pgxc scalability pg_open2012Ashutosh Bapat
 
M|18 Creating a Reference Architecture for High Availability at Nokia
M|18 Creating a Reference Architecture for High Availability at NokiaM|18 Creating a Reference Architecture for High Availability at Nokia
M|18 Creating a Reference Architecture for High Availability at NokiaMariaDB plc
 
Using oracle12c pluggable databases to archive
Using oracle12c pluggable databases to archiveUsing oracle12c pluggable databases to archive
Using oracle12c pluggable databases to archiveSecure-24
 
MariaDB MaxScale: an Intelligent Database Proxy
MariaDB MaxScale: an Intelligent Database ProxyMariaDB MaxScale: an Intelligent Database Proxy
MariaDB MaxScale: an Intelligent Database ProxyMarkus Mäkelä
 
Storage as a Service with Gluster
Storage as a Service with GlusterStorage as a Service with Gluster
Storage as a Service with GlusterVijay Bellur
 
Ch07 disaster recovery
Ch07 disaster recoveryCh07 disaster recovery
Ch07 disaster recoveryShane Flooks
 
Gluster fs current_features_and_roadmap
Gluster fs current_features_and_roadmapGluster fs current_features_and_roadmap
Gluster fs current_features_and_roadmapGluster.org
 
RocksDB detail
RocksDB detailRocksDB detail
RocksDB detailMIJIN AN
 
Gluster overview & future directions vault 2015
Gluster overview & future directions vault 2015Gluster overview & future directions vault 2015
Gluster overview & future directions vault 2015Vijay Bellur
 
Gluster.next feb-2016
Gluster.next feb-2016Gluster.next feb-2016
Gluster.next feb-2016Vijay Bellur
 
August 2013 HUG: Removing the NameNode's memory limitation
August 2013 HUG: Removing the NameNode's memory limitation August 2013 HUG: Removing the NameNode's memory limitation
August 2013 HUG: Removing the NameNode's memory limitation Yahoo Developer Network
 
Software defined storage
Software defined storageSoftware defined storage
Software defined storageGluster.org
 
Sdc challenges-2012
Sdc challenges-2012Sdc challenges-2012
Sdc challenges-2012Gluster.org
 
Tech Talk: RocksDB Slides by Dhruba Borthakur & Haobo Xu of Facebook
Tech Talk: RocksDB Slides by Dhruba Borthakur & Haobo Xu of FacebookTech Talk: RocksDB Slides by Dhruba Borthakur & Haobo Xu of Facebook
Tech Talk: RocksDB Slides by Dhruba Borthakur & Haobo Xu of FacebookThe Hive
 

What's hot (20)

Exchang Server 2013 chapter 2
Exchang Server 2013 chapter 2Exchang Server 2013 chapter 2
Exchang Server 2013 chapter 2
 
RocksDB compaction
RocksDB compactionRocksDB compaction
RocksDB compaction
 
Plugging in oracle database 12c pluggable databases
Plugging in   oracle database 12c pluggable databasesPlugging in   oracle database 12c pluggable databases
Plugging in oracle database 12c pluggable databases
 
1 technical-dns-workshop-day1
1 technical-dns-workshop-day11 technical-dns-workshop-day1
1 technical-dns-workshop-day1
 
Pgxc scalability pg_open2012
Pgxc scalability pg_open2012Pgxc scalability pg_open2012
Pgxc scalability pg_open2012
 
M|18 Creating a Reference Architecture for High Availability at Nokia
M|18 Creating a Reference Architecture for High Availability at NokiaM|18 Creating a Reference Architecture for High Availability at Nokia
M|18 Creating a Reference Architecture for High Availability at Nokia
 
Using oracle12c pluggable databases to archive
Using oracle12c pluggable databases to archiveUsing oracle12c pluggable databases to archive
Using oracle12c pluggable databases to archive
 
MariaDB MaxScale: an Intelligent Database Proxy
MariaDB MaxScale: an Intelligent Database ProxyMariaDB MaxScale: an Intelligent Database Proxy
MariaDB MaxScale: an Intelligent Database Proxy
 
운영체제론 Ch11
운영체제론 Ch11운영체제론 Ch11
운영체제론 Ch11
 
Storage as a Service with Gluster
Storage as a Service with GlusterStorage as a Service with Gluster
Storage as a Service with Gluster
 
Ch07 disaster recovery
Ch07 disaster recoveryCh07 disaster recovery
Ch07 disaster recovery
 
Gluster fs current_features_and_roadmap
Gluster fs current_features_and_roadmapGluster fs current_features_and_roadmap
Gluster fs current_features_and_roadmap
 
5 technical-dns-workshop-day3
5 technical-dns-workshop-day35 technical-dns-workshop-day3
5 technical-dns-workshop-day3
 
RocksDB detail
RocksDB detailRocksDB detail
RocksDB detail
 
Gluster overview & future directions vault 2015
Gluster overview & future directions vault 2015Gluster overview & future directions vault 2015
Gluster overview & future directions vault 2015
 
Gluster.next feb-2016
Gluster.next feb-2016Gluster.next feb-2016
Gluster.next feb-2016
 
August 2013 HUG: Removing the NameNode's memory limitation
August 2013 HUG: Removing the NameNode's memory limitation August 2013 HUG: Removing the NameNode's memory limitation
August 2013 HUG: Removing the NameNode's memory limitation
 
Software defined storage
Software defined storageSoftware defined storage
Software defined storage
 
Sdc challenges-2012
Sdc challenges-2012Sdc challenges-2012
Sdc challenges-2012
 
Tech Talk: RocksDB Slides by Dhruba Borthakur & Haobo Xu of Facebook
Tech Talk: RocksDB Slides by Dhruba Borthakur & Haobo Xu of FacebookTech Talk: RocksDB Slides by Dhruba Borthakur & Haobo Xu of Facebook
Tech Talk: RocksDB Slides by Dhruba Borthakur & Haobo Xu of Facebook
 

Similar to Dir based imp_5

Snooping protocols 3
Snooping protocols 3Snooping protocols 3
Snooping protocols 3Yasir Khan
 
Lessons from Sharding Solr
Lessons from Sharding SolrLessons from Sharding Solr
Lessons from Sharding SolrGregg Donovan
 
Lessons From Sharding Solr At Etsy: Presented by Gregg Donovan, Etsy
Lessons From Sharding Solr At Etsy: Presented by Gregg Donovan, EtsyLessons From Sharding Solr At Etsy: Presented by Gregg Donovan, Etsy
Lessons From Sharding Solr At Etsy: Presented by Gregg Donovan, EtsyLucidworks
 
Running a distributed system across kubernetes clusters - Kubecon North Ameri...
Running a distributed system across kubernetes clusters - Kubecon North Ameri...Running a distributed system across kubernetes clusters - Kubecon North Ameri...
Running a distributed system across kubernetes clusters - Kubecon North Ameri...Alex Robinson
 
Flink Forward San Francisco 2019: Moving from Lambda and Kappa Architectures ...
Flink Forward San Francisco 2019: Moving from Lambda and Kappa Architectures ...Flink Forward San Francisco 2019: Moving from Lambda and Kappa Architectures ...
Flink Forward San Francisco 2019: Moving from Lambda and Kappa Architectures ...Flink Forward
 
How is Kafka so Fast?
How is Kafka so Fast?How is Kafka so Fast?
How is Kafka so Fast?Ricardo Paiva
 
Scylla Summit 2016: Compose on Containing the Database
Scylla Summit 2016: Compose on Containing the DatabaseScylla Summit 2016: Compose on Containing the Database
Scylla Summit 2016: Compose on Containing the DatabaseScyllaDB
 
coa-Unit5-ppt1 (1).pptx
coa-Unit5-ppt1 (1).pptxcoa-Unit5-ppt1 (1).pptx
coa-Unit5-ppt1 (1).pptxRuhul Amin
 
Spil Storage Platform (Erlang) @ EUG-NL
Spil Storage Platform (Erlang) @ EUG-NLSpil Storage Platform (Erlang) @ EUG-NL
Spil Storage Platform (Erlang) @ EUG-NLThijs Terlouw
 
The Highs and Lows of Stateful Containers
The Highs and Lows of Stateful ContainersThe Highs and Lows of Stateful Containers
The Highs and Lows of Stateful ContainersC4Media
 
Scylla Summit 2016: Outbrain Case Study - Lowering Latency While Doing 20X IO...
Scylla Summit 2016: Outbrain Case Study - Lowering Latency While Doing 20X IO...Scylla Summit 2016: Outbrain Case Study - Lowering Latency While Doing 20X IO...
Scylla Summit 2016: Outbrain Case Study - Lowering Latency While Doing 20X IO...ScyllaDB
 
Cистема распределенного, масштабируемого и высоконадежного хранения данных дл...
Cистема распределенного, масштабируемого и высоконадежного хранения данных дл...Cистема распределенного, масштабируемого и высоконадежного хранения данных дл...
Cистема распределенного, масштабируемого и высоконадежного хранения данных дл...Ontico
 
Architecting for the cloud elasticity security
Architecting for the cloud elasticity securityArchitecting for the cloud elasticity security
Architecting for the cloud elasticity securityLen Bass
 
Stateful streaming and the challenge of state
Stateful streaming and the challenge of stateStateful streaming and the challenge of state
Stateful streaming and the challenge of stateYoni Farin
 
Managing Security At 1M Events a Second using Elasticsearch
Managing Security At 1M Events a Second using ElasticsearchManaging Security At 1M Events a Second using Elasticsearch
Managing Security At 1M Events a Second using ElasticsearchJoe Alex
 
An Efficient Backup and Replication of Storage
An Efficient Backup and Replication of StorageAn Efficient Backup and Replication of Storage
An Efficient Backup and Replication of StorageTakashi Hoshino
 
Openstack meetup lyon_2017-09-28
Openstack meetup lyon_2017-09-28Openstack meetup lyon_2017-09-28
Openstack meetup lyon_2017-09-28Xavier Lucas
 
Speed Up Presto at Uber with Alluxio Caching
Speed Up Presto at Uber with Alluxio CachingSpeed Up Presto at Uber with Alluxio Caching
Speed Up Presto at Uber with Alluxio CachingAlluxio, Inc.
 
247267395-1-Symmetric-and-distributed-shared-memory-architectures-ppt (1).ppt
247267395-1-Symmetric-and-distributed-shared-memory-architectures-ppt (1).ppt247267395-1-Symmetric-and-distributed-shared-memory-architectures-ppt (1).ppt
247267395-1-Symmetric-and-distributed-shared-memory-architectures-ppt (1).pptssuser5c9d4b1
 

Similar to Dir based imp_5 (20)

Snooping protocols 3
Snooping protocols 3Snooping protocols 3
Snooping protocols 3
 
Lessons from Sharding Solr
Lessons from Sharding SolrLessons from Sharding Solr
Lessons from Sharding Solr
 
Lessons From Sharding Solr At Etsy: Presented by Gregg Donovan, Etsy
Lessons From Sharding Solr At Etsy: Presented by Gregg Donovan, EtsyLessons From Sharding Solr At Etsy: Presented by Gregg Donovan, Etsy
Lessons From Sharding Solr At Etsy: Presented by Gregg Donovan, Etsy
 
Running a distributed system across kubernetes clusters - Kubecon North Ameri...
Running a distributed system across kubernetes clusters - Kubecon North Ameri...Running a distributed system across kubernetes clusters - Kubecon North Ameri...
Running a distributed system across kubernetes clusters - Kubecon North Ameri...
 
Flink Forward San Francisco 2019: Moving from Lambda and Kappa Architectures ...
Flink Forward San Francisco 2019: Moving from Lambda and Kappa Architectures ...Flink Forward San Francisco 2019: Moving from Lambda and Kappa Architectures ...
Flink Forward San Francisco 2019: Moving from Lambda and Kappa Architectures ...
 
How is Kafka so Fast?
How is Kafka so Fast?How is Kafka so Fast?
How is Kafka so Fast?
 
Scylla Summit 2016: Compose on Containing the Database
Scylla Summit 2016: Compose on Containing the DatabaseScylla Summit 2016: Compose on Containing the Database
Scylla Summit 2016: Compose on Containing the Database
 
Snooping 2
Snooping 2Snooping 2
Snooping 2
 
coa-Unit5-ppt1 (1).pptx
coa-Unit5-ppt1 (1).pptxcoa-Unit5-ppt1 (1).pptx
coa-Unit5-ppt1 (1).pptx
 
Spil Storage Platform (Erlang) @ EUG-NL
Spil Storage Platform (Erlang) @ EUG-NLSpil Storage Platform (Erlang) @ EUG-NL
Spil Storage Platform (Erlang) @ EUG-NL
 
The Highs and Lows of Stateful Containers
The Highs and Lows of Stateful ContainersThe Highs and Lows of Stateful Containers
The Highs and Lows of Stateful Containers
 
Scylla Summit 2016: Outbrain Case Study - Lowering Latency While Doing 20X IO...
Scylla Summit 2016: Outbrain Case Study - Lowering Latency While Doing 20X IO...Scylla Summit 2016: Outbrain Case Study - Lowering Latency While Doing 20X IO...
Scylla Summit 2016: Outbrain Case Study - Lowering Latency While Doing 20X IO...
 
Cистема распределенного, масштабируемого и высоконадежного хранения данных дл...
Cистема распределенного, масштабируемого и высоконадежного хранения данных дл...Cистема распределенного, масштабируемого и высоконадежного хранения данных дл...
Cистема распределенного, масштабируемого и высоконадежного хранения данных дл...
 
Architecting for the cloud elasticity security
Architecting for the cloud elasticity securityArchitecting for the cloud elasticity security
Architecting for the cloud elasticity security
 
Stateful streaming and the challenge of state
Stateful streaming and the challenge of stateStateful streaming and the challenge of state
Stateful streaming and the challenge of state
 
Managing Security At 1M Events a Second using Elasticsearch
Managing Security At 1M Events a Second using ElasticsearchManaging Security At 1M Events a Second using Elasticsearch
Managing Security At 1M Events a Second using Elasticsearch
 
An Efficient Backup and Replication of Storage
An Efficient Backup and Replication of StorageAn Efficient Backup and Replication of Storage
An Efficient Backup and Replication of Storage
 
Openstack meetup lyon_2017-09-28
Openstack meetup lyon_2017-09-28Openstack meetup lyon_2017-09-28
Openstack meetup lyon_2017-09-28
 
Speed Up Presto at Uber with Alluxio Caching
Speed Up Presto at Uber with Alluxio CachingSpeed Up Presto at Uber with Alluxio Caching
Speed Up Presto at Uber with Alluxio Caching
 
247267395-1-Symmetric-and-distributed-shared-memory-architectures-ppt (1).ppt
247267395-1-Symmetric-and-distributed-shared-memory-architectures-ppt (1).ppt247267395-1-Symmetric-and-distributed-shared-memory-architectures-ppt (1).ppt
247267395-1-Symmetric-and-distributed-shared-memory-architectures-ppt (1).ppt
 

More from Yasir Khan (20)

Lecture 6
Lecture 6Lecture 6
Lecture 6
 
Lecture 4
Lecture 4Lecture 4
Lecture 4
 
Lecture 3
Lecture 3Lecture 3
Lecture 3
 
Lecture 2
Lecture 2Lecture 2
Lecture 2
 
Lec#1
Lec#1Lec#1
Lec#1
 
Ch10 (1)
Ch10 (1)Ch10 (1)
Ch10 (1)
 
Ch09
Ch09Ch09
Ch09
 
Ch05
Ch05Ch05
Ch05
 
Introduction 1
Introduction 1Introduction 1
Introduction 1
 
Hpc sys
Hpc sysHpc sys
Hpc sys
 
Hpc 6 7
Hpc 6 7Hpc 6 7
Hpc 6 7
 
Hpc 4 5
Hpc 4 5Hpc 4 5
Hpc 4 5
 
Hpc 3
Hpc 3Hpc 3
Hpc 3
 
Hpc 2
Hpc 2Hpc 2
Hpc 2
 
Hpc 1
Hpc 1Hpc 1
Hpc 1
 
Flynns classification
Flynns classificationFlynns classification
Flynns classification
 
Natural Language Processing
Natural Language ProcessingNatural Language Processing
Natural Language Processing
 
Uncertainity
Uncertainity Uncertainity
Uncertainity
 
Logic
LogicLogic
Logic
 
M6 game
M6 gameM6 game
M6 game
 

Recently uploaded

Mixin Classes in Odoo 17 How to Extend Models Using Mixin Classes
Mixin Classes in Odoo 17  How to Extend Models Using Mixin ClassesMixin Classes in Odoo 17  How to Extend Models Using Mixin Classes
Mixin Classes in Odoo 17 How to Extend Models Using Mixin ClassesCeline George
 
The basics of sentences session 2pptx copy.pptx
The basics of sentences session 2pptx copy.pptxThe basics of sentences session 2pptx copy.pptx
The basics of sentences session 2pptx copy.pptxheathfieldcps1
 
Measures of Central Tendency: Mean, Median and Mode
Measures of Central Tendency: Mean, Median and ModeMeasures of Central Tendency: Mean, Median and Mode
Measures of Central Tendency: Mean, Median and ModeThiyagu K
 
An Overview of Mutual Funds Bcom Project.pdf
An Overview of Mutual Funds Bcom Project.pdfAn Overview of Mutual Funds Bcom Project.pdf
An Overview of Mutual Funds Bcom Project.pdfSanaAli374401
 
Accessible design: Minimum effort, maximum impact
Accessible design: Minimum effort, maximum impactAccessible design: Minimum effort, maximum impact
Accessible design: Minimum effort, maximum impactdawncurless
 
psychiatric nursing HISTORY COLLECTION .docx
psychiatric  nursing HISTORY  COLLECTION  .docxpsychiatric  nursing HISTORY  COLLECTION  .docx
psychiatric nursing HISTORY COLLECTION .docxPoojaSen20
 
Ecological Succession. ( ECOSYSTEM, B. Pharmacy, 1st Year, Sem-II, Environmen...
Ecological Succession. ( ECOSYSTEM, B. Pharmacy, 1st Year, Sem-II, Environmen...Ecological Succession. ( ECOSYSTEM, B. Pharmacy, 1st Year, Sem-II, Environmen...
Ecological Succession. ( ECOSYSTEM, B. Pharmacy, 1st Year, Sem-II, Environmen...Shubhangi Sonawane
 
1029 - Danh muc Sach Giao Khoa 10 . pdf
1029 -  Danh muc Sach Giao Khoa 10 . pdf1029 -  Danh muc Sach Giao Khoa 10 . pdf
1029 - Danh muc Sach Giao Khoa 10 . pdfQucHHunhnh
 
Unit-V; Pricing (Pharma Marketing Management).pptx
Unit-V; Pricing (Pharma Marketing Management).pptxUnit-V; Pricing (Pharma Marketing Management).pptx
Unit-V; Pricing (Pharma Marketing Management).pptxVishalSingh1417
 
Class 11th Physics NEET formula sheet pdf
Class 11th Physics NEET formula sheet pdfClass 11th Physics NEET formula sheet pdf
Class 11th Physics NEET formula sheet pdfAyushMahapatra5
 
Basic Civil Engineering first year Notes- Chapter 4 Building.pptx
Basic Civil Engineering first year Notes- Chapter 4 Building.pptxBasic Civil Engineering first year Notes- Chapter 4 Building.pptx
Basic Civil Engineering first year Notes- Chapter 4 Building.pptxDenish Jangid
 
Explore beautiful and ugly buildings. Mathematics helps us create beautiful d...
Explore beautiful and ugly buildings. Mathematics helps us create beautiful d...Explore beautiful and ugly buildings. Mathematics helps us create beautiful d...
Explore beautiful and ugly buildings. Mathematics helps us create beautiful d...christianmathematics
 
APM Welcome, APM North West Network Conference, Synergies Across Sectors
APM Welcome, APM North West Network Conference, Synergies Across SectorsAPM Welcome, APM North West Network Conference, Synergies Across Sectors
APM Welcome, APM North West Network Conference, Synergies Across SectorsAssociation for Project Management
 
Application orientated numerical on hev.ppt
Application orientated numerical on hev.pptApplication orientated numerical on hev.ppt
Application orientated numerical on hev.pptRamjanShidvankar
 
Gardella_PRCampaignConclusion Pitch Letter
Gardella_PRCampaignConclusion Pitch LetterGardella_PRCampaignConclusion Pitch Letter
Gardella_PRCampaignConclusion Pitch LetterMateoGardella
 
Making and Justifying Mathematical Decisions.pdf
Making and Justifying Mathematical Decisions.pdfMaking and Justifying Mathematical Decisions.pdf
Making and Justifying Mathematical Decisions.pdfChris Hunter
 
Activity 01 - Artificial Culture (1).pdf
Activity 01 - Artificial Culture (1).pdfActivity 01 - Artificial Culture (1).pdf
Activity 01 - Artificial Culture (1).pdfciinovamais
 

Recently uploaded (20)

Código Creativo y Arte de Software | Unidad 1
Código Creativo y Arte de Software | Unidad 1Código Creativo y Arte de Software | Unidad 1
Código Creativo y Arte de Software | Unidad 1
 
Mixin Classes in Odoo 17 How to Extend Models Using Mixin Classes
Mixin Classes in Odoo 17  How to Extend Models Using Mixin ClassesMixin Classes in Odoo 17  How to Extend Models Using Mixin Classes
Mixin Classes in Odoo 17 How to Extend Models Using Mixin Classes
 
The basics of sentences session 2pptx copy.pptx
The basics of sentences session 2pptx copy.pptxThe basics of sentences session 2pptx copy.pptx
The basics of sentences session 2pptx copy.pptx
 
Measures of Central Tendency: Mean, Median and Mode
Measures of Central Tendency: Mean, Median and ModeMeasures of Central Tendency: Mean, Median and Mode
Measures of Central Tendency: Mean, Median and Mode
 
An Overview of Mutual Funds Bcom Project.pdf
An Overview of Mutual Funds Bcom Project.pdfAn Overview of Mutual Funds Bcom Project.pdf
An Overview of Mutual Funds Bcom Project.pdf
 
Accessible design: Minimum effort, maximum impact
Accessible design: Minimum effort, maximum impactAccessible design: Minimum effort, maximum impact
Accessible design: Minimum effort, maximum impact
 
psychiatric nursing HISTORY COLLECTION .docx
psychiatric  nursing HISTORY  COLLECTION  .docxpsychiatric  nursing HISTORY  COLLECTION  .docx
psychiatric nursing HISTORY COLLECTION .docx
 
Ecological Succession. ( ECOSYSTEM, B. Pharmacy, 1st Year, Sem-II, Environmen...
Ecological Succession. ( ECOSYSTEM, B. Pharmacy, 1st Year, Sem-II, Environmen...Ecological Succession. ( ECOSYSTEM, B. Pharmacy, 1st Year, Sem-II, Environmen...
Ecological Succession. ( ECOSYSTEM, B. Pharmacy, 1st Year, Sem-II, Environmen...
 
INDIA QUIZ 2024 RLAC DELHI UNIVERSITY.pptx
INDIA QUIZ 2024 RLAC DELHI UNIVERSITY.pptxINDIA QUIZ 2024 RLAC DELHI UNIVERSITY.pptx
INDIA QUIZ 2024 RLAC DELHI UNIVERSITY.pptx
 
1029 - Danh muc Sach Giao Khoa 10 . pdf
1029 -  Danh muc Sach Giao Khoa 10 . pdf1029 -  Danh muc Sach Giao Khoa 10 . pdf
1029 - Danh muc Sach Giao Khoa 10 . pdf
 
Unit-V; Pricing (Pharma Marketing Management).pptx
Unit-V; Pricing (Pharma Marketing Management).pptxUnit-V; Pricing (Pharma Marketing Management).pptx
Unit-V; Pricing (Pharma Marketing Management).pptx
 
Class 11th Physics NEET formula sheet pdf
Class 11th Physics NEET formula sheet pdfClass 11th Physics NEET formula sheet pdf
Class 11th Physics NEET formula sheet pdf
 
Basic Civil Engineering first year Notes- Chapter 4 Building.pptx
Basic Civil Engineering first year Notes- Chapter 4 Building.pptxBasic Civil Engineering first year Notes- Chapter 4 Building.pptx
Basic Civil Engineering first year Notes- Chapter 4 Building.pptx
 
Explore beautiful and ugly buildings. Mathematics helps us create beautiful d...
Explore beautiful and ugly buildings. Mathematics helps us create beautiful d...Explore beautiful and ugly buildings. Mathematics helps us create beautiful d...
Explore beautiful and ugly buildings. Mathematics helps us create beautiful d...
 
Mattingly "AI & Prompt Design: The Basics of Prompt Design"
Mattingly "AI & Prompt Design: The Basics of Prompt Design"Mattingly "AI & Prompt Design: The Basics of Prompt Design"
Mattingly "AI & Prompt Design: The Basics of Prompt Design"
 
APM Welcome, APM North West Network Conference, Synergies Across Sectors
APM Welcome, APM North West Network Conference, Synergies Across SectorsAPM Welcome, APM North West Network Conference, Synergies Across Sectors
APM Welcome, APM North West Network Conference, Synergies Across Sectors
 
Application orientated numerical on hev.ppt
Application orientated numerical on hev.pptApplication orientated numerical on hev.ppt
Application orientated numerical on hev.ppt
 
Gardella_PRCampaignConclusion Pitch Letter
Gardella_PRCampaignConclusion Pitch LetterGardella_PRCampaignConclusion Pitch Letter
Gardella_PRCampaignConclusion Pitch Letter
 
Making and Justifying Mathematical Decisions.pdf
Making and Justifying Mathematical Decisions.pdfMaking and Justifying Mathematical Decisions.pdf
Making and Justifying Mathematical Decisions.pdf
 
Activity 01 - Artificial Culture (1).pdf
Activity 01 - Artificial Culture (1).pdfActivity 01 - Artificial Culture (1).pdf
Activity 01 - Artificial Culture (1).pdf
 

Dir based imp_5

  • 1. 1 Directory Protocols • Topics: directory-based cache coherence implementations
  • 2. 2 Flat Memory-Based Directories Main memory Cache 1 Cache 2 Cache 64 … … Block size = 128 B Memory in each node = 1 GB Cache in each node = 1 MB For 64 nodes and 64-bit directory, Directory size = 4 GB For 64 nodes and 12-bit directory, Directory size = 0.75 GB
  • 3. 3 Flat Memory-Based Directories L2 cache L1 Cache 1 L1 Cache 2 L1 Cache 64 … … Block size = 64 B L2 cache in each node = 1 MB L1 Cache in each node = 64 KB For 64 nodes and 64-bit directory, Directory size = 8 MB For 64 nodes and 12-bit directory, Directory size = 1.5 MB
  • 4. 4 Flat Cache-Based Directories Main memory… Block size = 128 B Memory in each node = 1 GB Cache in each node = 1 MB 6-bit storage in DRAM for each block; DRAM overhead = 0.375 GB 12-bit storage in SRAM for each block; SRAM overhead = 0.75 MB Cache 7 Cache 3 Cache 26
  • 5. 5 Flat Cache-Based Directories Main memory… 6-bit storage in L2 for each block; L2 overhead = 0.75 MB 12-bit storage in L1 for each block; L1 overhead = 96 KB Cache 7 Cache 3 Cache 26 Block size = 64 B L2 cache in each node = 1 MB L1 Cache in each node = 64 KB
  • 6. 6 Flat Cache-Based Directories • The directory at the memory home node only stores a pointer to the first cached copy – the caches store pointers to the next and previous sharers (a doubly linked list) • Potentially lower storage, no bottleneck for network traffic, • Invalidates are now serialized (takes longer to acquire exclusive access), replacements must update linked list, must handle race conditions while updating list
  • 7. 7 Serializing Writes for Coherence • Potential problems: updates may be re-ordered by the network; General solution: do not start the next write until the previous one has completed • Strategies for buffering writes:  buffer at home: requires more storage at home node  buffer at requestors: the request is forwarded to the previous requestor and a linked list is formed  NACK and retry: the home node nacks all requests until the outstanding request has completed
  • 8. 8 SGI Origin 2000 • Flat memory-based directory protocol • Uses a bit vector directory representation • Two processors per node, but there is no snooping protocol within a node – combining multiple processors in a node reduces cost P L2 CA M/D P L2 Interconnect
  • 9. 9 Protocol States • Each memory block has seven states • Three stable states: unowned, shared, exclusive (either dirty or clean) • Three busy states indicate that the home has not completed the previous request for that block (read, read-excl or upgrade, uncached read) • Poison state – used for lazy TLB shootdown
  • 10. 10 Handling Reads • When the home receives a read request, it looks up memory (speculative read) and directory in parallel • Actions taken for each directory state:  shared or unowned: memory copy is clean, data is returned to requestor, state is changed to excl if there are no other sharers  busy: a NACK is sent to the requestor  exclusive: home is not the owner, request is fwded to owner, owner sends data to requestor and home
  • 11. 11 Inner Details of Handling the Read • The block is in exclusive state – memory may or may not have a clean copy – it is speculatively read anyway • The directory state is set to busy-exclusive and the presence vector is updated • In addition to fwding the request to the owner, the memory copy is speculatively forwarded to the requestor  Case 1: excl-dirty: owner sends block to requestor and home, the speculatively sent data is over-written  Case 2: excl-clean: owner sends an ack (without data) to requestor and home, requestor waits for this ack before it moves on with speculatively sent data
  • 12. 12 Inner Details II • Why did we send the block speculatively to the requestor if it does not save traffic or latency?  the R10K cache controller is programmed to not respond with data if it has a block in excl-clean state  when an excl-clean block is replaced from the cache, the directory need not be updated – hence, directory cannot rely on the owner to provide data and speculatively provides data on its own
  • 13. 13 Handling Write Requests • The home node must invalidate all sharers and all invalidations must be acked (to the requestor), the requestor is informed of the number of invalidates to expect • Actions taken for each state:  shared: invalidates are sent, state is changed to excl, data and num-sharers is sent to requestor, the requestor cannot continue until it receives all acks (Note: the directory does not maintain busy state, subsequent requests will be fwded to new owner and they must be buffered until the previous write has completed)
  • 14. 14 Handling Writes II • Actions taken for each state:  unowned: if the request was an upgrade and not a read-exclusive, is there a problem?  exclusive: is there a problem if the request was an upgrade? In case of a read-exclusive: directory is set to busy, speculative reply is sent to requestor, invalidate is sent to owner, owner sends data to requestor (if dirty), and a “transfer of ownership” message (no data) to home to change out of busy  busy: the request is NACKed and the requestor must try again
  • 15. 15 Handling Write-Back • When a dirty block is replaced, a writeback is generated and the home sends back an ack • Can the directory state be shared when a writeback is received by the directory? • Actions taken for each directory state:  exclusive: change directory state to unowned and send an ack  busy: a request and the writeback have crossed paths: the writeback changes directory state to shared or excl (depending on the busy state), memory is updated, and home sends data to requestor, the intervention request is dropped
  • 16. 16 Serialization • Note that the directory serializes writes to a location, but does not know when a write/read has completed at any processor • For example, a read reply may be floating on the network and may reach the requestor much later – in the meantime, the directory has already issued a number of invalidates, the invalidate is overwritten when the read reply finally shows up – hence, each node must buffer its requests until outstanding requests have completed
  • 17. 17 Serialization - II • Assume that a dirty block is being passed from P1 to another writer P2, the “ownership transfer” message from P1 to home takes a long time, P2 receives its data and carries on, P2 does a writeback  protocol must be designed to handle this case correctly If the writeback is from the node that placed the directory in busy state, the writeback is NACKed (If instead, the writeback was allowed to proceed, at some later point, if the directory was expecting an “ownership transfer”, it may mis-interpret the “floating” message)
  • 18. 18 Directory Structure • The system supports either a 16-bit or 64-bit directory (fixed cost) • For small systems, the directory works as a full bit vector representation • For larger systems, a coarse vector is employed – each bit represents p/64 nodes • State is maintained for each node, not each processor – the communication assist broadcasts requests to both processors
  • 19. 19 Page Migration • Each page in memory has an array of counters to detect if a page has more misses from a node other than home • When a page is moved to a different physical memory location, the virtual address remains the same, but the page table and TLBs must be updated • To reduce the cost of TLB shootdown, the old page sets its directory state to poisoned – if a process tries to access this page, the OS intervenes and updates the translation