Как работает распределенная общая память при наличии кеша и регистров?

Недавно я прочитал несколько статей, описывающих DSM.

Некоторые из них пытались обеспечить последовательную согласованность. Я понимаю, как работает алгоритм и как он использует обработчик ошибок страниц для его выполнения. Но меня озадачивает то, что, хотя сама память имеет последовательную согласованность, кеш и регистр на каждой машине могут нарушить модель последовательной согласованности.

Как это работает с кешем/регистрами?

Даже DSM, поддерживающий упрощенную согласованность (например, документ TreadMarks), который выполняет всю синхронизацию в операциях Lock()/Unlock, все еще имеет ту же проблему:

Как он обрабатывает кэш и регистрацию, чтобы предотвратить частное копирование на каждом компьютере?


distributed-computing distributed-system
person Oliver Young    schedule 09.08.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

DSM должен быть расширен до DCSM (+ лучше всего с интеллектуальным управлением вне-NUMA)

Архитектура распределенной когерентной общей памяти ( DCSM ) как форма такой подходящей архитектуры памяти, в которой физически отдельные области памяти по-прежнему могут быть адресованы как одно непрерывное, логически совместно используемое адресное пространство.

Чтобы эта концепция работала, как указано выше, слово «Coherent» является ключевым ( и управление NUMA / L1, L2, {L3 | local-memory } контролирует все филигранные внутренние функции ЦП из регистров в локальные кэши и память процессора).

Доступные в отрасли надежные реализации DCSM должны решить саму проблему согласованности, чтобы когда-либо стать возможными, и пользовательское представление такой базовой системы DCSM, таким образом, является просто представлением большого / толстого монолитного (абстрактного) хоста, где в несмотря на столько тысяч процессоров и все физически распределенные вычислительные ресурсы (включая процессоры, блоки DRAM-памяти, все виды устройств ввода-вывода, включая хранилище, все сетевые интерфейсы и т. д.), вся инфраструктура, интегрированная с DCSM, по-прежнему остается согласованным высокопроизводительным "супер"-хостом.

Таким образом, не ожидается и не требуется прямого взаимодействия с пользовательским кодом, и можно раскрутить любой устаревший код, имея теперь несколько 8000+ ЦП + XYZ [ТБ] ОЗУ в качестве когерентное пространство для чисто вычислений в оперативной памяти (где XYZ недавно может масштабироваться до диапазонов выше нескольких сотен, если не тысяч, ограниченных больше бюджетом, чем в принципе).

Можно легко почувствовать, чего ожидать от такого вычислительного устройства, имея под капотом такого зверя с такими огромными вычислительными ресурсами, где пользовательский код не нуждается и не беспокоится о том, как/где физически используется реальный ресурс, как Абстракция на уровне операционной системы заставляет пользовательский код исходить из того, что он просто существует и согласованно работает "в" такой инфраструктуре DCSM с распределенными вычислительными ресурсами.

Разве это не здорово?

person user3666197    schedule 10.08.2017
comment
Итак, мы должны решить проблему, вызванную кешем/регистром, чтобы обеспечить модель согласованности, верно? Это вообще не упоминается в документах (например, TreadMarks). Вот почему мне интересно. Кроме того, какую модель согласованности обычно предоставляет промышленный DCSM? Я не думаю, что последовательная согласованность (CS) вообще возможна с точки зрения производительности. Чтобы обеспечить CS, не только разделяемая память должна быть CS, но и нам нужно сбрасывать регистр/кеш каждый раз, когда мы пытаемся записать в память, верно? - person Oliver Young; 10.08.2017
comment
Короче говоря, это выходит далеко за рамки формата S/O. Да, хотя я согласен с тем, что многие основные проблемы информатики были подняты и решены буквально десятилетия назад, Келехер и др. работали в эпохи, когда аппаратное обеспечение было несравнимо проще ( { NUMA- | кеш- | суперскалярный оптимизированный конвейерный дизайн кремния -}-мудрый), чем современные кремниевые конструкции. Суть в том, что мы развернули такой дизайн распределенной системы, который прозрачно разрешил DCSM для пользовательского кода, и мы можем оставаться в душевном спокойствии (и забыть о мелочах DCSM) и полагаться на его сервис. - person user3666197; 10.08.2017
comment
В любом случае, спасибо, что упомянули документы RICE / Keleher и др. — они вернули меня в тот день, когда существовали Digital Equipment Corporation + Ultrix O/S, когда DSM был способом выйти за рамки исключительно редкого и дорогого оборудования SMP, когда ISO- Асинхронный режим передачи OSI-L2 Ячейки 48 + 5 байт были в конечном итоге лучшим и наиболее разумным соответствием для глобальной синхронной транспортной инфраструктуры SDH / SONET (позже потерянной в ex-post ToS, помеченных службами доставки с максимальным усилием). Действительно прекрасные дни, полные ярких умов и умных идей :о) Излишне спрашивать, почему толпа двинулась в сторону с куда более бедными игрушками... - person user3666197; 10.08.2017