Переполнение адреса

We use cookies. Read the Privacy and Cookie Policy

Переполнение адреса

Так как мы решили не использовать на System/38 48-разрядный адрес повторно до следующей перезагрузки, встал вопрос о том, что однажды все доступные адреса могут быть исчерпаны. В поисках ответа на него, мы провели некоторые интересные подсчеты. В соответствии с их результатами, если выполнять одну IPL в день 365 дней в году, то повторное использование номера IPL потребуется через 180 лет. Итак, опасности, что расширения идентификаторов сегментов будут повторяться, не существовало. Зная проектируемую производительность будущих процессоров, мы могли вычислить максимальное число 64-килобайтных сегментов, которое будет сгенерировано в интервале между ежедневными IPL. Эти расчеты также показали, что проблемы нет. И все же прогноз оказался неверным — некоторые большие AS/400 стали выходить за границы адресов[ 67 ].

Что же случилось? Во-первых, одна IPL в день — это неплохое допущение для ранних System/38, но после того как многие заказчики стали использовать свои компьютеры 24 часа в сутки, времени на перезагрузку не осталось. Кроме того, наши системы сильно увеличились в размерах, и время IPL стало слишком большим. С тех пор мы внесли существенные изменения в AS/400, что позволило сократить время IPL до нескольких минут. Но даже при этом одна IPL в день была неверным допущением. Второй ошибкой в вычислениях было предположение о 64-килобайтном сегменте. Используя представление адреса 24/24 оригинальный VMC всегда создавал 16-мегабайтные сегменты.

Ситуация усугублялась тем, что компонент управления основной памятью в оригинальном VMC разделял полное 48-разрядное виртуальное адресное пространство на квадранты. Старшие два разряда адреса задавали квадрант в зависимости от назначения последнего. Один квадрант был зарезервирован для адресов постоянных объектов, так что у всех постоянных адресов два старших разряда были одинаковы. Другой квадрант был выделен адресам для временных объектов, третий — для адресов временных объектов групп доступа[ 68 ]. Так как постоянные объекты не могут входить в группу доступа, то четвертый квадрант не использовался. Такое решение было принято в предположении, что 48-разрядное адресное пространство настолько велико, что на одну его четверть можно безболезненно «закрыть глаза». Из 256 ТБ (248 байтов) виртуальной памяти, которыми мы так любили похваляться, 64 ТБ никогда не использовались в System/38 и первых моделях AS/400.

Проблема, возникшая в некоторых больших системах AS/400, состояла в выходе за пределы диапазона временных адресов. Эта проблема получила название переполнения идентификатора сегмента, так как все идентификаторы сегментов, доступные в интервалах между перезагрузками, были использованы. При разделении адресного пространства на квадранты на каждую IPL приходилось лишь по 4 миллиона 16-мегабайтных временных сегментов. Вследствие этого, большие системы с приложениями, использовавшими много временных объектов, выходили за пределы диапазона временных идентификаторов сегментов, если не перегружались по несколько дней. С точки зрения пользователя, положение можно было исправить довольно просто — перезагрузить систему[ 69 ]. Но причин происшедшего это паллиативное решение не устраняло.

8первые версии ОС для AS/400 были внесены изменения, позволявшие уменьшить проблему переполнения адресов. Компоненты стали использовать 64-килобай-тные сегменты вместо 16-мегабайтных, везде, где было возможно. Был также задействован ранее выброшенный квадрант адресного пространства. Разумеется, эти изменения не решили проблему, но они позволили нам продержаться до появления новых RISC-процессоров.

Проблема касалась и постоянных адресов. Их максимальное число ограничено объемом дискового пространства на подключенных к системе устройствах, поскольку даже удаленные объекты продолжают занимать некоторое место на диске. Мы ограничили общий объем дискового пространства, которое могло быть подключено к AS/ 400, чтобы пользователь не мог исчерпать постоянные адреса. Ведь выход за пределы постоянных адресов нельзя исправить с помощью IPL, здесь потребуется полная переустановка системы, что, разумеется, совершенно неприемлемо.

Я потратил несколько разделов на описание структуры адресации System/38 и первых моделей AS/400, чтобы показать причины, заставившие IBM перейти на RISC-процессоры. Еще до выпуска первой AS/400 мы знали, что 48-разрядный адрес ограничивает будущий рост системы. По мере увеличения размеров и скорости работы, системы начинали использовать все больше временных адресов. Заказчики же хотели подключать все больший объем дисков.

Нам потребовалось некоторое время, чтобы убедить руководство в невозможности использовать 48-разрядный адрес в будущих системах. В Рочестере всегда была популярна старая поговорка: «Не надо чинить то, что не ломается». И вот, наконец, мы убедили менеджеров, что то, что сломалось, сломалось безвозвратно. Хорошо еще то, что поломка случилась внутри системы. Независимость AS/400 от технологии защитила наших заказчиков.

Если в вычислительной архитектуре изменяются адреса, то приходится менять и все остальное. Мы восприняли случившееся как шанс избавиться от IMPI и перейти на RISC. Наш первый RISC-процессор, который мы начали разрабатывать в 1990 году и назвали С-RISC («С» — обозначает коммерческий), имел 96-разрядный адрес. У нас появилось место для такого большого адреса в указателях, и мы не стали стесняться. Когда в 1991 году было принято решение использовать архитектуру PowerPC, размер адреса был сокращен до 64 разрядов.