WikiDer > Протокол дракона

Dragon protocol

В Протокол Дракона[1] это обновление на основе согласованность кеша протокол, используемый в мультипроцессор системы. Распространение записи выполняется путем прямого обновления всех кешированный значения на нескольких процессорах. Протоколы на основе обновлений, такие как протокол Dragon, работают эффективно, когда за записью в блок кэша следует несколько чтений, сделанных другими процессорами, поскольку обновленный блок кеша легко доступен через кеши, связанные со всеми процессорами.

состояния

Каждый блок кэша находится в одном из четырех состояний: исключительная очистка, общая очистка, общая модификация и изменение.

  • Эксклюзивно-чистый (E): Это означает, что блок кэша был сначала получен текущим процессором и с тех пор к нему не обращались никакие другие процессоры.
  • Общая уборка (Sc): Это означает, что блок кеша определенно существует в кешах нескольких процессоров, и что текущий процессор не последний, который записывает блок. Состояния E и Sc поддерживаются протоколом отдельно, чтобы предотвратить операции чтения-записи в блоках кэша, которые не используются совместно, вызывая транзакции на шине и, следовательно, замедляя выполнение. Это обычное явление в однопоточных программах.
  • Общий измененный (Sm): Это означает, что блок существует в кэше нескольких процессоров, и текущий процессор является последним, который изменил блок. Следовательно, текущий процессор называется владельцем блока. В отличие от протоколов аннулирования, блок не должен обновляться в основной памяти, а только в процессоре. Ответственность за обновление основной памяти при удалении блока кэша лежит на процессоре.
  • Изменить (M): Это означает, что только один процессор имеет блок памяти, а также что он изменил значение, так как оно было перенесено из памяти.

Для любой данной пары кешей разрешенные состояния данного блока кеша в сочетании с состояниями других состояний кеша следующие (состояния сокращены в указанном выше порядке):

E Sc См M
EКрасный XNКрасный XNКрасный XNКрасный XN
ScКрасный XNЗеленая галочкаYЗеленая галочкаYКрасный XN
СмКрасный XNЗеленая галочкаYКрасный XNКрасный XN
MКрасный XNКрасный XNКрасный XNКрасный XN

Сделки

Есть 4 транзакции процессора и 2 транзакции шины.

Чтение процессора (PrRd): Это происходит, когда процессор завершает успешное чтение определенного блока кэша, помещенного в его кэш.

Запись процессора (PrWr): Это происходит, когда процессор завершает успешную запись в определенный блок кэша, помещенный в его кэш. Это делает процессор самым последним для обновления блока кэша.

Ошибка чтения процессора (PrRdMiss): Это происходит, когда процессору не удается прочитать блок кэша из своего кеша, и ему необходимо извлечь блок из памяти или другого кеша.

Ошибка записи процессора (PrWrMiss): Это происходит, когда процессору не удается выполнить запись в блок кеша из своего кеша, и ему необходимо получить блок из памяти или другого кеша, а затем записать в него. Это снова заставляет процессор обновлять блок кэша последним.

Автобусное чтение (BusRd): Это происходит, когда процессор запрашивает шину для получения последнего значения блока кеша, будь то из основной памяти или кеша другого процессора.

Промывать: Это происходит, когда процессор помещает на шину весь блок кэша. Это должно отражать изменения, внесенные процессором в кэшированный блок в основной памяти.

Обновление автобуса (BusUpd): Это происходит, когда процессор изменяет блок кэша, а другим процессорам требуется обновление соответствующих блоков кеша. Это уникально только для записи протоколов обновления. BusUpd занимает меньше времени по сравнению с операцией сброса, поскольку запись в кэш выполняется быстрее, чем в память. Также следует отметить, что кеш не может обновить свою локальную копию блока кеша, а затем запросить шину отправить обновление шины. Если это произойдет, то возможно, что два кэша независимо обновят свою локальную копию, а затем запросят шину. Тогда они увидят одновременно две записи, которые не последуют Последовательная согласованность.

А общая линия также требуется, чтобы указать, доступен ли определенный блок кеша в нескольких кэшах. Это необходимо, потому что один из кешей может вытеснить блок без необходимости обновлять другие блоки. Общая линия помогает уменьшить количество транзакций памяти и шины в некоторых случаях, когда блок доступен только в одном кэше и, следовательно, обновление шины не требуется. Такая выделенная линия для обнаружения совместного использования наблюдается во всех протоколах записи-обновления, таких как Протокол светлячка и реализован на основе стандартов шины, таких как Futurebus (Стандарт IEEE P896.1).[2]

Переходы

Протокол Dragon - транзакции, инициированные процессором

Переходы, инициированные процессором

В зависимости от текущего состояния блока и транзакции, инициированной процессором, блок кэша подвергается одному из следующих переходов состояния:

  • Когда процессор не считывает (PrRdMiss), а блок кеша не используется совместно, состояние переходит в Эксклюзивный
  • Когда процессор не считывает (PrRdMiss), и блок кеша является общим, состояние переходит в состояние Общая чистка
  • Когда процессор пропустил запись (PrWrMiss), а блок кеша является общим, состояние переходит в Общий Изменено и процессор становится владельцем.
  • Когда процессор пропустил запись (PrWrMiss), а блок кеша не используется совместно, состояние переходит в Изменено
  • Когда идет чтение процессора (PrRd), состояние блока кэша не изменяется и сохраняет значение. Это потому, что это просто команда чтения, и она не генерирует никаких транзакций шины.
  • Если блок кеша находится в Изменено состояние, а процессор пишет (PrWr ) блок, перехода нет, так как блок не используется совместно.
  • Когда блок кеша находится в Общий Изменено состояние, а процессор записывает (PrWr), но общая линия не утверждается, состояние переходит в Изменено.
  • Если блок кеша находится в Общий Изменено состояние, когда запись (PrWr) происходит и утверждается общая линия, обновление шины (BusUpd) создается для обновления другого блока кеша.
  • Если блок кеша находится в Общий Чистый состояние, когда запись (PrWr) происходит и утверждается общая линия, обновление шины (BusUpd) создается для обновления другого блока кэша, и состояние изменяется на Shared Modified.
  • Но если блок кеша находится в Общий Чистый состояние, когда запись (PrWr) возникает, но общая линия не утверждается, состояние переходит в Изменено, и автобусные транзакции не генерируются.
  • Когда блок в Эксклюзивный состояние, а процессор пишет (PrWr) к нему он будет изменен на Изменено штат.
Протокол Dragon - транзакции, инициированные шиной

Переходы, инициированные шиной

В зависимости от текущего состояния блока и транзакции, инициированной шиной, блок кэша подвергается одному из следующих переходов состояний:

  • Если блок кеша находится в Изменено, и автобусное чтение (BusRd) выдается Промывать выдается для обновления основной памяти, и состояние переходит в Общий Изменено, так как блок теперь находится в нескольких кешах.
  • Если блок кеша находится в Общий Изменено состояние, а автобус читал (BusRd), а Промывать выдается для обновления основной памяти, а состояние остается прежним.
  • Если блок кеша находится в Общий Изменено состояние и обновление шины (BusUpd) транзакция оформлена, состояние переходит в Общий Чистый, все кеши обновлены.
  • Если блок кеша находится в Общий Чистый состояние, и он получает чтение шины (BusRd) или обновление автобуса (BusUpd) он продолжает сохранять свое состояние, поскольку значение все еще используется совместно. Однако в случае обновления он обновит значение в блоке кеша.
  • Если блок кеша находится в Эксклюзивный состояние и шина считывает значение (BusRd), состояние перейдет в Shared Clean, поскольку блок больше не находится только в одном кэше.

Варианты дизайна низкого уровня

Устранение состояния Shared-Modified

Процессор с блоком кэша в состоянии Sm отвечает за обновление памяти при замене блока кэша. Но если основная память обновляется всякий раз, когда происходит транзакция обновления шины, нет необходимости в отдельных состояниях Sm и Sc, и протокол может позволить себе одно общее состояние. Однако это вызывает намного больше транзакций с памятью.[3] что может замедлить работу системы, особенно когда несколько процессоров записывают в один и тот же блок кеша.

Трансляция замены блока Sc

Протокол позволяет заменять блоки кэша в состоянии Sc в автоматическом режиме без какой-либо активности шины. Если была сделана широковещательная рассылка, чтобы другие кеши знали о замене блока Sc, они могли бы протестировать общую линию и перейти в состояние E, если не было других разделяющих сторон. Преимущество наличия блока в состоянии E состоит в том, что если блок будет записан позже, он перейдет в состояние M и нет необходимости генерировать транзакцию обновления шины. Таким образом, за счет трансляции замен блоков Sc мы можем избежать транзакций обновления шины. А поскольку широковещательная передача замен не критична по времени, если кеш-память не требуется для обработки замены сразу, обратная сторона медали. С другой стороны, если кэш не обрабатывает обновление сразу, это может привести к неупорядоченным обновлениям. В таких случаях протокол обновления с тремя состояниями, например Светляк протокол, может иметь преимущества в производительности.

Сравнения

Дракон против записи делает недействительными протоколы

Запись недействительна - это еще один набор согласованность кеша протоколы, где после изменения блока кеша другие значения того же блока в других кэшах не обновляются, а становятся недействительными.[4] Протоколы аннулирования записи более эффективны в случаях, когда происходит много последующих записей в один и тот же блок кеша, поскольку аннулирование происходит один раз, и дальнейшие транзакции шины другими процессорами избегаются. Однако протокол обновления записи более эффективен в случаях, когда за записью в блок следует несколько чтений в один и тот же блок. Поскольку мы обновляем другие кешированные значения, как только мы их записываем, они сразу получают доступ к данным. В таком случае. протокол аннулирования записи очень невыгоден, потому что каждый раз, когда блок кэша изменяется в другом кэше, остальные необходимые кеши будут сталкиваться с ошибкой отсутствие согласованности, и инициируйте транзакцию шины, чтобы прочитать новое значение. Напротив, протокол обновления записи имеет тенденцию временами сохранять значения блока обновленными дольше, чем необходимо, что приведет к увеличению других типов промахов, т. Е. конфликт и вместимость пропускает.

Протокол дракона против светлячка

В случае Светлякпередача измененных блоков из кэша в кэш одновременно записывается обратно в основную память. Но поскольку доступ к основной памяти на порядки медленнее по сравнению с кешами, требуется дополнительная сложность выполнения обратной записи как отдельной операции шины. В любом случае это приводит к снижению производительности.[5] Этой проблемы можно полностью избежать в случае протокола Dragon, поскольку общие блоки вообще не записываются обратно в память. Однако это происходит за счет одного добавленного состояния (Shared-modified).

использованная литература

  1. ^ Аткинсон, Рассел Р .; МакКрайт, Эдвард М. (01.01.1987). Процессор Dragon. Труды Второй Международной конференции по архитектурной поддержке языков программирования и операционных систем. АСПЛОС II. Лос-Аламитос, Калифорния, США: Издательство компьютерного общества IEEE. С. 65–69. Дои:10.1145/36206.36185 (неактивно 01.09.2020). ISBN 978-0818608056.CS1 maint: DOI неактивен по состоянию на сентябрь 2020 г. (ссылка на сайт)
  2. ^ Стенстрём, Пер (01.06.1990). «Обзор схем когерентности кэша для мультипроцессоров». Компьютер. 23 (6): 12–24. Дои:10.1109/2.55497. ISSN 0018-9162.
  3. ^ Каллер, Дэвид; Сингх, Джасвиндер Пал; Гупта, Ануп (1999). Архитектура параллельного компьютера, 1-е издание | Дэвид Каллер, Джасвиндер Пал Сингх, Ануп Гупта |. store.elsevier.com. ISBN 9781558603431. Получено 2016-10-24.
  4. ^ Солихин, Ян (2015). Основы параллельной многоядерной архитектуры. Чепмен и Холл / CRC. С. 205–206, 231–232. ISBN 9781482211184.
  5. ^ Арчибальд, Джеймс; Баер, Жан-Лу (1986-09-01). «Протоколы согласованности кэша: оценка с использованием модели многопроцессорного моделирования». ACM Trans. Comput. Syst. 4 (4): 273–298. Дои:10.1145/6513.6514. ISSN 0734-2071. S2CID 713808.

Смотрите также