<<
>>

СОМА-мультипроцессоры

ИиМА- и СС-ИиМА-машины обладают одним серьезным недостатком: обращения к удаленной памяти выполняются гораздо медленнее, чем к локальной. В ССЖиМА-машине эта разница в производительности в какой-то степени нивелируется за счет кэш-памяти.
Однако если объем запрашиваемых удаленных данных значительно превышает вместимость кэш-памяти, постоянно будут происходить кэш-промахи, что негативно скажется на производительности.

Мы уже знаем, что достаточно высокую производительность имеют UMA-ма- шины, но число процессоров в них невелико, к тому же они довольно дороги. NC-NUMA-машины хорошо масштабируются, но в них требуется ручное или полуавтоматическое размещение страниц памяти, результаты которого часто плачевны. Дело в том, что очень непросто предсказать, где и какие страницы могут понадобиться, кроме того, страницы трудно перемещать из-за их больших размеров. CC-NUMA-машины, такие как мультипроцессор Sun Fire Е25К, начинают работать очень медленно, если большому числу процессоров требуются большие объемы удаленных данных.

Так или иначе, каждая из этих схем имеет существенные недостатки.

Однако существует мультипроцессор, в котором все эти проблемы решаются за счет использования основной памяти каждого процессора в качестве кэш-памяти. Такая система называется СОМА (Cache Only Memory Access — доступ только к кэш-памяти). В ней страницы не имеют собственных «домашних» машин, как в системах NUMA и CC-NUMA, фактически, страницы в этой системе вообще не имеют «прописки».

Вместо этого физическое адресное пространство делится на строки кэша, которые по запросу свободно перемещаются в системе. Блоки памяти не имеют собственных машин. У них, как у кочевников в некоторых странах третьего мира, дом там, где они оказались. Память, которая привлекает строки по мере необходимости, называется притягивающей.

Использование основной памяти в качестве большого кэша увеличивает процент кэш-попаданий, а, следовательно, и производительность.

К сожалению, ничего идеального не бывает. С системой СОМА связаны две новые проблемы:

♦ Как размещаются строки кэша?

♦ Что делать, когда удаляемая из памяти строка является последней копией?

Первая проблема связана со следующим фактом. Как известно, диспетчер памяти выполняет трансляцию виртуального адреса в физический. Если после трансляции оказывается, что строки нет в «настоящем» аппаратном кэше, очень трудно сказать, есть вообще искомая строка в основной памяти или ее там нет. Аппаратная поддержка механизма разбиения памяти на страницы здесь не поможет, поскольку каждая страница состоит из большого количества отдельных строк кэша, которые располагаются в системе независимо друг от друга. Даже если известно, что строки в основной памяти нет, как выяснить, где она есть? В данном случае нельзя спросить об этом «домашнюю» машину потерявшейся страницы, поскольку таковой машины в системе просто нет.

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

Другое решение — отображать страницы целиком, но при этом не требовать наличия всех строк кэша. Тогда для каждой страницы потребуется аппаратно построить битовую карту, где каждой строке соответствует 1 бит, который и укажет на присутствие или отсутствие этой строки. В этой схеме, которая называется простой схемой СОМА, если строка присутствует, она должна находиться в правильной позиции на своей странице. Если она отсутствует, то любая попытка использовать ее должна вызывать исключение, которое позволит программно найти и задействовать нужную строку.

Таким образом, система будет искать только те строки, которые действительно находятся в удаленной памяти.

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

Вторая проблема связана с удалением последней копии. Как и в CC-NUMA- машине, строка кэша может одновременно находиться в нескольких узлах. Если происходит кэш-промах, строку нужно прочитать, а это обычно означает ее удаление. А что произойдет, если выбранная строка окажется последней копией? В этом случае ее нельзя удалять.

Одно из возможных решений — вернуться к каталогу и проверить, существуют ли другие копии. Если да, то строку можно смело удалять. Если нет, ее нужно где-то разместить. Другое решение — пометить одну из копий каждой строки кэша как главную и никогда ее не удалять. При таком подходе проверять каталог не потребуется. В любом случае СОМА-машина потенциально должна иметь более высокую производительность, чем CC-NUMA, но пока было создано всего несколько СОМА-машин, а для реализации всего их потенциала нужно накопить некоторый опыт. Первыми СОМА-машинами были KSR-1 [34] и Data Diffusion Machine [83]. В качестве более свежего примера можно привести SDAARC [62].

<< | >>
Источник: Таненбаум Э.. Архитектура компьютера. 5-е изд. 2007

Еще по теме СОМА-мультипроцессоры:

  1. I. 1. 3. Особенности системного подхода в психологии.
  2. Введение
  3. I. 2. 2. Специфика объектов психологии.
  4. 2.5. Нефункциональное поведение
  5. АМЕРИКА – КАЗАХСТАН: ТАК ЛИ БЛИЗКО ТО ДАЛЕКО?
  6. АПОЛОГИЯ ИЛИ О МАГИИ
  7. Л.О. Доліненко, В.О. Доліненко, С.О. Сарновська. Цивільне право України, 2006
  8. ЦИВІЛЬНЕ ПРАВО УКРАЇНИ
  9. ПЕРЕДМОВА
  10. Частина І ПРОГРАМА КУРСУ «ЦИВІЛЬНЕ ПРАВО УКРАЇНИ»
  11. Розділ І. Загальні положення цивільного права
  12. Тема 1. Поняття цивільного права. Предмет та метод, система цивільного права. Функції та принципи цивільного права
  13. Тема 2. Цивільне законодавство України