Будет ли mmap использовать непрерывную память? (on solaris)

Question

Я использовал mmap (просто попытаюсь понять, как работает mmap), чтобы выделить 96k анонимную память, но похоже, что он разделяет 96k на 64k и 32k. Но при распределении 960k он выделяет только один кусок размером 960k. Когда солярис разделит память на несколько частей? Код:

#define PROT PROT_READ | PROT_WRITE 
#define MAP MAP_ANON | MAP_PRIVATE 
if ((src = mmap(0, 88304, PROT, MAP, -1, 0)) == MAP_FAILED) 
    printf("mmap error for input"); 

if ((src = mmap(0, 983040, PROT, MAP, -1, 0)) == MAP_FAILED) 
    printf("mmap error for input"); 

if ((src = mmap(0, 98304, PROT, MAP, -1, 0)) == MAP_FAILED) 
    printf("mmap error for input"); 

стропильных:

mmap(0x00000000, 88304, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) 
    = 0xFFFFFFFF7E900000 
mmap(0x00000000, 983040, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) 
    = 0xFFFFFFFF7E800000 
mmap(0x00000000, 98304, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) 
    = 0xFFFFFFFF7E700000 

PMAP:

FFFFFFFF7E700000   64  -   -   - rw--- [anon] 
    ==> strange is that for 96k, it was broken into 2 part. 
FFFFFFFF7E710000   32  -   -   - rw--- [anon] 
FFFFFFFF7E800000  960  -   -   - rw--- [anon] 
FFFFFFFF7E900000   64  -   -   - rw--- [anon] 
FFFFFFFF7E910000   24  -   -   - rw--- [anon] 
FFFFFFFF7EA00000   64  -   -   - rw--- [anon] 
FFFFFFFF7EA10000   32  -   -   - rw--- [anon] 

Answer 1

Это является непрерывной памяти, вы можете сказать по адресам (F...700000 + 64K = F...710000), так что я не думаю, что у вас есть беспокоиться об этом. Я вполне уверен, что mmap требуется для того, чтобы предоставить вам непрерывную память в вашем адресном пространстве. Это было бы совершенно бесполезно, так как оно дает только один базовый адрес. С двумя несмежными блоками не было бы способа найти этот второй блок.

Так что, я думаю, ваш вопрос: почему это отображается как два блока в pmap?

На что я отвечаю: «Наполненный, если я знаю». Но я могу сделать разумную догадку, которая лучше всех может надеяться на меня в это утро (предварительный кофе).

Я бы предположил, что эти блоки были выделены перед другим процессом (или двумя) и были выпущены обратно в диспетчер памяти mmap. Я вижу две возможности о том, что менеджер памяти срастается блоки, чтобы сделать большие свободные блоки, либо:

• он делает это, как только память освобождается (не так, как ваши выходные данные показывают, что это не происходит) ,
• он делает это периодически, и он не добрался до него, прежде чем вы запросили свой блок 96K; или
• это совсем не беспокоит, потому что он достаточно умен, чтобы сделать это во время выделения вам блока.

Я подозреваю, что это последнее просто потому, что диспетчер памяти не имел проблем, предоставляя вам два блока для вашего запроса, поэтому он, очевидно, построен для его обработки. Блок 960K, вероятно, не сегментирован, потому что он появился из гораздо большего блока.

Имейте в виду, что это предположение (информированное, но все же предположение). Я видел немало внутренних компонентов UNIX (настоящих UNIX, а не нового парня на блоке :-), но мне никогда не приходилось вникать в mmap.

Answer 2

Я не могу вспомнить термин для него (полосы? Кусочки? Клинья? Argh), но Solaris выделяет разные размеры страниц из пулов разных размеров. Это оказывается несколько более эффективным, чем однородные размеры страниц, потому что он лучше использует карту памяти. Один из этих размеров - 32K, еще 64K, другой - 1024K, я считаю. Чтобы получить 96K, у вас есть 64 и 32, чтобы получить 960, вы получили большую часть 1024K.

Основным ресурсом для этого волшебства является книга Solaris Internals. Мой, к сожалению, находится в коробке в гараже у мамы.

Answer 3

Ответ зависит от того, что вы подразумеваете под смежным. Solaris и все современные Unix и unix-подобные системы (возможно, все современные операционные системы) будут разделять физическую память на страницы, а память на «странице» будет смежной на физическом уровне.В большинстве современных систем имеется аппаратный MMU (модуль управления памятью), который преобразует виртуальный адрес в физический адрес. Таким образом, системный вызов mmap возвращает смежное виртуальное адресное пространство, но этот виртуальный адрес будет управляться MMU, который может использовать несколько страниц в зависимости от размера страницы (ов) и размера отображения памяти.

Хотя весь виртуальный адрес будет смежным (внутри отображения) Адреса внутри «страниц» также будут физически смежными, но страницы и переходы между страницами могут быть даже не близки друг к другу физически.