#memory #memory-management #solaris
#память #управление памятью #solaris
Вопрос:
Как MS Windows, так и Oracle Linux позволяют 32-разрядным приложениям использовать > 4 ГБ памяти. Метод Windows — это AWE: адресуйте расширения окон, а метод Linux — это очень большая память.
Как это работает: 32-разрядное приложение не может напрямую обращаться к > 4 ГБ виртуальной памяти; но 64-разрядная ОС может, и 4 ГБ памяти слишком малы для некоторых приложений. Итак, VLM и AWE позволяют приложению резервировать огромный объем памяти из 64-разрядной ОС (или даже из 32-разрядной ОС с AWE). 32-разрядное приложение не может обращаться к этой памяти напрямую, но оно может попросить ОС настроить отображение некоторой части огромной памяти в первые 4 ГБ (в 32-разрядное виртуальное пространство), затем к этой памяти можно получить доступ, изменить; затем она размечается обратно (с запросом ОС).
Вопрос в том, есть ли что-то вроде VLM или AWE в Solaris OS (версии 10 или 11; x86_64 или sparc64)?
Комментарии:
1. AWE работает и на 32-разрядной ОС. Речь идет о замене виртуальных на физические сопоставления вместо использования большего виртуального адресного пространства основной операционной системы.
2. да, я знаю, и я сказал это в Q «с 32-разрядной ОС с БЛАГОГОВЕНИЕМ». Вопрос в том, есть ли в Solaris что-то вроде AWE / VLM?
3. @osgx, пожалуйста, дайте мне знать, если вы нашли ответ во внешнем источнике.
4. @Anders, если VLM работает через создание ramdisk (tmpfs / shmfs), а затем создает множество файлов среднего размера или один огромный файл, а затем использует mmap / munmap необходимых частей данных.. Тогда, я думаю, solaris способен сделать то же самое. Одновременно доступно не более 4 ГБ, но многие ГБ оперативной памяти доступны в mmap-ed «windows» (регионы). Программное обеспечение, конечно, должно быть обновлено для поддержки этого.
5. @osgx, вы всегда можете создать mmap обычного большого файла и полагаться на буферизацию, чтобы сохранить используемые части в памяти. Я не могу проверить прямо сейчас, но я почти уверен, что в Solaris есть tmpfs, поэтому вы можете отображать файлы в tmpfs.
Ответ №1:
Насколько мне известно, библиотеки нет, но реализовать ее было бы довольно просто под Solaris (и всеми Unix / подобными ОС, поддерживающими tmpfs и mmap).
Просто создайте файл нужного размера (например, 16 Гигабайт) в /tmp (при условии, что / tmp находится в tmpfs, конфигурации по умолчанию) и попросите процесс (ы) сопоставить различные области этого файла для доступа к памяти с требуемыми смещениями.
Если вы действительно хотите получить доступ к физической памяти, а не к виртуальной, вы можете использовать поддержку Solaris ramdisk (ramdiskadm) вместо tmpfs.
Ответ №2:
Solaris поддерживает PAE (расширение физического адреса), но поиск в Google не рисует приятной картины. Доступно очень мало информации, и большая ее часть — это грозные предупреждения о том, что куча сторонних драйверов не будет с ней работать.
Комментарии:
1. Вопрос не в PAE, речь идет о 32-разрядной программе на 64-разрядной ОС. 64-разрядной ОС не нужен PAE для использования > 4 ГБ памяти, потому что он может напрямую адресовать 2 ^ 64 (виртуально) или 2 ^ 36-2 ^ 40 (физически). Но 32-разрядная программа не может обработать > 4 ГБ памяти, и даже PAE ничего не может с этим поделать. (PAE не изменился
sizeof(void*); это только позволяет ОС отображать большую физическую память в меньшие 4 ГБ памяти, которая является виртуальной памятью или адресуется памятью программы)2. В любом случае, «сопоставление виртуальных и физических адресов» управляется ОС, а VLM — это технология совместной работы ОС и пользовательского пространства.
3. @osgx: Вы правы. Однако и VLM, и AWE полагаются на PAE. Если вы не можете запустить PAE на Solaris, вы не сможете адресовать более 4 ГБ.
4. Нет. VLM не полагается на PAE. 64-разрядная ОС (это мой случай) не полагается на PAE. PAE — это не только метод доступа > 4 ГБ даже для 32-разрядной ОС: другой — PSE36: en.wikipedia.org/wiki/PSE-36