В подобной конфигурации в каждом цикле памяти к ней может осуществляться несколько параллельных обращений, что фактически устраняет проблемы, связанные с использованием одной шины памяти на традиционных системах 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 в следующее столетие.

Часто возникает некая терминологическая путаница: что, собственно, является операционной системой 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.

Конечно, все функции OS/400 присутствуют в LIC в том смысле, что они должны использовать MI для обращения к аппаратуре. Но часто инструкция на ЯВУ после преобразования в соответствующую форму MI транслируется в команды PowerPC (или старого IMPI) напрямую, без каких-то особых структур данных или вызовов процедур LIC. Считать, что некоторая системная функция реализована OS/400, а не LIC, можно в тех случаях, если реализующий ее код видим OS/400 и необходимые структуры данных находятся в объектах OS/400 или в их видимых частях.