Фрэнк Солтис - Основы AS/400
Пример подобной конфигурации с двенадцатью процессорами Вы можете увидеть на рисунке 2.6. На одной плате — четыре процессора Apache вместе с четырьмя кэшами L2. В 12-процессорной конфигурации установлено три таких платы. Размещенные на платах кэши L2 размером 4 или 8 мегабайт обладают цикличностью в 8 наносекунд. Таким образом, за один цикл процессора между кэшем второго уровня и кэшем данных или команд первого уровня в микросхеме Apache может быть передано 16 байтов (см. рисунок 2.5).
Основная память в данной конфигурации может достигать 20 гигабайт, каждая плата памяти — содержать до гигабайта, так что на рисунке 2.6 показаны 20 таких плат. Обратите внимание на наличие четырех банков памяти с одинаковым числом плат в каждом, что позволяет обеспечить прослоенную память (memory interleaving) — технический прием, при котором открывается доступ к последовательным блокам данных памяти через разные банки. Например, если каждая плата памяти имеет 8-байтовый интерфейс, то одновременно из четырех банков памяти может быть считано 32 последовательных байта (байты 0-7 из банка 1, байты 8-15 из банка 2 и т. д.).
Четыре перекрестных переключателя подсистемы памяти UMA обеспечивают соединение между кэшами второго уровня и платами основной памяти. Три шины данных 6хх — по одной на каждую плату процессора — соединяют 12 процессоров с каждым из четырех переключателей. Эти 128-разрядные шины данных имеют время цикла 12 наносекунд (в полтора раза больше времени цикла процессора). Дополнительная шина данных 6хх соединяет с каждым из переключателей памяти подсистему ввода-вывода. У каждого переключателя — два независимых 128-разрядных интерфейса к платам памяти.
В подобной конфигурации в каждом цикле памяти к ней может осуществляться несколько параллельных обращений, что фактически устраняет проблемы, связанные с использованием одной шины памяти на традиционных системах SMP.
Имейте в виду, что здесь представлена лишь одна из возможных конфигураций соединения процессорных плат, переключателей и плат памяти. Другие модели линии AS/400 будут использовать иные комбинации этих компонентов. Например, в 4-процессорной конфигурации SMP может использоваться одна процессорная плата, два переключателя и четыре банка памяти.
Также, обратите внимание, что переключатели используются только линиями данных. Линии адресах всех кэшей второго уровня (показанные на рисунке как адресные линии 6хх) общие, что позволяет обычное отслеживание адресов, иначе называемое снупингом кэша (cache snooping) — прием, при котором каждый контроллер кэша L2 постоянно отслеживает все адреса, передаваемые по общей адресной шине. Кроме того, контроллеры проверяют, содержится ли адрес на шине в их кэше. Если это так, то соответствующие данные кэша становятся недействительными. Таким образом достигается когерентность информации во всех кэшах, ведь общие данные могут быть изменены одновременно не более чем одним процессором.
На рисунке 2.6 также показана общая подсистема ввода-вывода. Для подключения устройства расширения ввода-вывода к корпусу Mako, в котором размещается 12-процессорная конфигурация, используется SAN (System Area Network). Два таких интерфейса показаны на рисунке. В главе 10 мы рассмотрим использование SAN для поддержки разных интерфейсов ввода-вывода в AS/400е и соединения этих систем друг с другом.
Рисунок 2.6 12-конфигурация SMP
Итак, причина использования перекрестных переключателей — стремление повысить эффективность, или, иначе говоря, процентный рост производительности SMP при добавлении нового процессора в конфигурацию. Во многих системах с разделяемой памятью эта эффективность равна примерно 70 процентам при использовании от четырех до восьми процессоров.[ 25 ] Благодаря новой подсистеме памяти, процессоры Apache должны поднять эффективность до 85—90 процентов.
Будущее переключателей памяти
Если используются иерархии кэшей, то почему бы не использовать иерархии переключателей? Фактически, именно это и произойдет в будущем. Мы рассмотрели пример, где каждый процессор был соединен посредством шины 6хх с каждым из четырех переключателей. А ведь вместо этого можно установить на каждый четырех процессорный узел один переключатель, который, логично назвать контроллером узла. Такие контроллеры могут быть подключены к набору переключателей, которые, в свою очередь, подключаются к банку плат памяти. Можно также подключить контроллеры узлов к нескольким наборам переключателей, а каждый из этих наборов — к отдельным банкам памяти. Таким образом будет получена очень большая конфигурация SMP. Вспомните этот разговор после выхода четвертого поколения процессоров Рочестера!
Вы еще не забыли про компьютер IBM ASCI Blue Pacific? В нем будет 512 процессорных узлов по восемь процессоров в каждом и подсистема памяти UMA на переключателях. Не следует ожидать в скором времени появления столь мощной версии AS/400, но разве не приятно осознавать, что такая конфигурация возможна, даже если и не очень практична? В конце концов, кодовым названием System/38 было Pacific[ 26 ], и мы действительно собирались создать по-настоящему большую систему. Ну что ж, посмотрим, как будут выглядеть рочестерские процессоры PowerPC следующего поколения...
Выводы
Сегодня 64-разрядный процессор стал стандартом в компьютерной промышленности. Все RISC-процессоры AS/400 — современные, 64-разрядные, способные обеспечить функциональные возможности и производительность, необходимую для коммерческих систем и серверов. Мы считаем, что семейство RISC-процессоров PowerPC приведет AS/400 в следующее столетие.
Глава 3
System Licensed Internal Code (SLIC) —сердце AS/400
Часто возникает некая терминологическая путаница: что, собственно, является операционной системой AS/400? Первое, что приходит в голову — ну, конечно, это Operating System/400 (OS/400); в конце концов, иначе ее не называли бы так. И все же такой ответ неверен. OS/400 нельзя признать операционной системой AS/400, так как в ней не предусмотрены большинство функций, присущих другим ОС.
В главе 1 мы определили ОС как набор программ, управляющих системными ресурсами и предоставляющих базу для написания прикладных программ. Мы также оговорили, что законченный набор API для написания приложений для AS/400 — это MI, высокоуровневый машинный интерфейс. Таким образом, на вторую часть вопроса мы ответили. Осталось решить, где же находятся программы, управляющие системными ресурсами.
И снова ответ «OS/400» будет неверен. Компоненты традиционной ОС выполняют такие функции как управление памятью, процессами, программами и вводом-выводом. Но, обычно, эти низкоуровневые функции сильно зависят от аппаратуры и тесно связаны с нижележащими физическими структурами. Например, компонент управления памятью должен «знать» точную конфигурацию и характеристики иерархии памяти. Независящий от технологии интерфейс MI не обладает этими качествами. Следовательно, управление памятью должно осуществляться ниже MI, OS/400 же, наоборот, расположена выше. Следовательно, ни одна из таких аппаратно-зависимых компонент не может быть в ее составе, этого не допускает основное условие задачи — независимость от технологии.
Итак, благодаря расположению аппаратно-зависимых компонентов ниже MI, последний защищает прикладные программы и OS/400 от аппаратных изменений. ПО операционной системы, расположенное ниже MI, называется LIC (licensed internal code).
Давайте еще раз взглянем на структуру AS/400. Теперь очевидно: OS/400 состоит из объектов и программ поверх MI, а LIC составляют структуры данных и программы ниже MI. Таким образом, LIC связывает MI и аппаратуру. Фактически, ОС AS/ 400 — сочетание OS/400 и LIC. Получается, что AS/400 представляет собой пирог, в котором OS/400 играет роль глазури, а LIC — начинки между слоями.
В последние годы такую нижнюю часть ОС в других системах стали называть ядром. Есть много определений того, что именно относится к ядру операционной системы. Некоторые педанты могли бы сказать, что LIC содержит гораздо больше функций операционной системы, чем, обычное ядро. И все же термин ядро наиболее удобнен для описания функций ОС, реализованных ниже MI.
Разделяй и властвуй
Очевидно, что некоторые компоненты ОС, такие как управление памятью, реализованы в LIC. Для других компонентов это не столь очевидно. Возьмем, например, базу данных. Некоторым ее частям необходима информация о физических дисковых устройствах и о пересылке данных в системе, другие же — могут быть написаны аппа-ратно независимо. Проектировщики обязаны решить, где разместить ПО базы данных — целиком в OS/400, целиком в LIC или и там, и там.
Рискуя забежать вперед (подробно мы рассмотрим MI в главе 4) должен отметить, что, говоря о разделении на OS/400 и LIC, я имею в виду объекты MI, реализованные в LIC. Позже мы подробней остановимся на системных объектах MI, реализованных в LIC, и на объектах OS/400, реализованных только MI.
