Почему ОС не может использовать все 64 бита для обращения? Почему только 48 битов?
Я читаю "Понимание Ядро Linux".
Подкачка страниц для 64-разрядной архитектуры
Как мы видели в предыдущих разделах, двухуровневая подкачка страниц является наиболее часто используемой 32-разрядными микропроцессорами. Двухуровневая подкачка страниц, однако, не подходит для компьютеров, которые принимают 64-разрядную архитектуру. Давайте использовать мысленный эксперимент для объяснения почему:
Запустите путем принятия стандартного размера страницы 4 КБ. Поскольку 1 КБ покрывает диапазон 210 адресов, 4 КБ покрывает 212 адресов, таким образом, поле Offset составляет 12 битов. Это оставляет до 52 битов линейного адреса, который будет распределен между Таблицей и полями Directory. Если мы теперь решаем использовать только 48 из 64 битов для обращения (это ограничение оставляет нас с удобными 256 ТБ адресного пространства!), оставление 48-12 = 36 битов должны будут быть разделены среди Таблицы и полей Directory. Если мы теперь решаем зарезервировать 18 битов для каждого из этих двух полей, и Каталог Страницы и Таблицы страниц каждого процесса должны включать 218 записей то есть, больше чем 256 000 записей.
"Если мы теперь решаем использовать только 48 из 64 битов для обращения". Почему? И Почему только 48 битов? Почему не некоторое другое число?
Ну, я - просто постоянный пользователь ПК и программист. Его просто твердый полагать для меня, что 32-разрядное обращение т.е. 4 ГБ (2GB/3GB, чтобы быть более корректным) адресное пространство для каждого процесса является пределом. Если Вы действительно встретились с этим пределом. Дайте мне пример.
Каков этот предел для окон?
Я знаю ту виртуальную память! = физическая память и контакты адреса процессора не имеют никакого отношения к виртуальной памяти. Это - совершенно другой вопрос. Как знать количество контактов адреса (= размер адресной шины) для процессора. спецификации http://ark.intel.com процессора не включают эту спецификацию.
Ответ:
См. ответ Paul Betts для разумного ответа для 1-го вопроса.
6 ответов
"Если мы теперь решим использовать только 48 из 64 бит для адресации". Почему? И почему только 48 бит? Почему не какое-то другое число?
Системные архитекторы идут на компромиссы. 256 ТБ кажется более чем достаточным местом для адресного пространства одного процесса. Помните, что виртуальный адрес = физический адрес, и вообще говоря, каждый процесс имеет свое собственное адресное пространство.
Пока указатели имеют 64 бита, это скорее вопрос производительности, чем чего-либо еще. Если и когда 48 бит станут ограничением, ОС может быть настроена на использование большего количества бит 64-битного адресного пространства без нарушения несовместимости приложений. Пока же архитекторы просто покупают себе очень удобный промежуток времени.
Это может быть связано с возможностями виртуальной адресации на стороне процессора, поскольку многие процессоры теперь имеют блоки управления памятью для обработки отображения виртуальной -> физической памяти.
Как узнать количество адресных выводов (= размер шины адреса) для процессора. http://ark.intel.com спецификации процессора не включают эту спецификацию.
По большей части это не имеет значения. Это способ для процессора реализовать различные схемы физической адресации. 64-разрядный процессор может получить внешние шины адреса/данных для своего полного адресного пространства с 64, 32, 16, 8, 4, 2 или 1 адресным выводом, если шина синхронна и адресные биты мультиплексируются во времени. Опять же, виртуальный адрес != физический адрес; 64-битная виртуальная адресация может быть реализована с 48- или 32-битными физическими адресами (просто вы будете ограничены 248 или 232 словами памяти).
обновление: если вы действительно хотите знать, вы должны посмотреть в техническом описании каждого процессора, о котором идет речь. Например, Intel Core 2 Duo - в разделе 4.2 технического описания говорится о сигналах - адресная шина имеет ширину 36 бит (но на самом деле это 33 сигнальные линии; ширина данных составляет 64 бита = 8 байт, поэтому остальные 3 линии, вероятно, не нужны при правильном выравнивании данных)
Ну, я обычный пользователь ПК и программист. Мне просто трудно поверить, что 32-битная адресация, т.е. 4GB (2GB/3GB, если быть более корректным) адресного пространства на процесс - это предел. Если вы действительно сталкивались с этим ограничением. Пожалуйста, приведите пример.
Два слова: memory-mapped files.
Мне просто трудно поверить, что 32-битная адресация, то есть ... 4 ГБ (2 ГБ / 3 ГБ, если быть точнее) адресного пространства на процесс, является пределом. Если вы действительно столкнулись с этим пределом. Приведите мне пример.
Получить данные из ОЗУ эффективнее (быстрее), чем с диска.
Скорость SQL-сервера частично зависит от того, сколько данных (например, сколько страниц индекса и данных) он может хранить в ОЗУ, а не на диске.
Таким образом, базы данных SQL (например) могут быть быстрее на машинах с более чем 4 ГБ ОЗУ.
То же самое верно и для других типов серверов (например, файловых серверов, HTTP-прокси и т. Д.), Которые могут быть быстрее, если у них могут быть большие кеши RAM.
Ни одна текущая конструкция x86-64 не использует для этого более 48 бит - так что это удобное число для выбора, и оно автоматически является таким же ограничением и в Windows.
Ни один из этих ответов не является правильным. Причина, по которой ОС не используют полные 64-битные версии, заключается в том, что таблицы страниц будут намного больше (64-битные версии уже имеют 3 уровня таблицы страниц), и нет причин платить за дополнительную косвенность, достаточно 48 бит. 48 битов также удобно, потому что у вас есть дополнительные биты для хранения флагов (тегирование указателя)
Мне просто трудно поверить, что 32-битная адресация, то есть ... 4 ГБ (2 ГБ / 3 ГБ, если быть точнее) адресного пространства на процесс, является пределом. Если вы действительно столкнулись с этим пределом. Приведите мне пример.
Его больше не существует (за исключением некоторых старых персональных компьютеров сотрудников), но я работал над набором программного обеспечения под названием RealiMation еще в конце 1990-х - начале 2000-х. Это был 3D-движок реального времени для визуализации и моделирования. Один из наших клиентов регулярно создавал модели с высокой детализацией, объем памяти которых превышал 2 ГБ. Мы загружали текстуры на лету по мере необходимости, и нам приходилось добавлять код для проверки сбоя выделения памяти, чтобы мы могли продолжить отображение модели, хотя и без текстур.
Думаю, самый простой ответ - закон Мура.
Закон Мура в основном гласит, что стоимость ИС снижается вдвое каждые 18 месяцев. Есть несколько способов интерпретировать это: объем памяти, установленной на ПК, имеет тенденцию удваиваться каждые 18 месяцев. Эффективная скорость удваивается (по крайней мере, если брать ядра * МГц, а не только МГц).
В любом случае, у нас действительно закончилось 32-битное адресное пространство, поэтому переход с 32 на 48 означает, что на аппаратной стороне мы выделили пространство расширения примерно для 16 итераций закона Мура, что составляет примерно 20 годы.
Я почти уверен, что, хотя некоторые ПК могут быть доведены до 10-летней отметки, 20-летний запас возможностей расширения кажется достойным компромиссом: через 20 лет компьютеры будут другими - они не будут использовать одни и те же процессоры и Шины RAM, какими они были 20 лет назад. Проектирование интерфейса с запасом на 20 лет - это просто глупо по сравнению с разработкой, которая в любом случае никогда не найдет применения.
И это не так уж и мало, чтобы существующее оборудование могло оказаться устаревшим слишком рано.