LINUX.ORG.RU

Непрерывность выделения памяти - виртуальная и физическая

 


0

4

Проясните ситуацию, пожалуйста:

В программе выделяем массив размером 1ГБ. В виртуальном адресном пространстве программы он будет выделен в виде непрерывной области.

Если overcommit разрешается, то в C++ выделение по new вернет исключение, только если не нашлось даже виртуальной памяти. Так?

Теперь начинаем обращаться к адресам этого массива. Ядро будет выделять память страницами, и совсем не факт, что эти страницы будут лежать последовательно. Так?

При последовательном проходе по массиву CPU начнет выполнять prefetching следующих данных. Это делается по виртуальным или по физическим адресам? Будет ли сбиваться prefetch на границах физических страниц памяти, которые лежат не последовательно?

Можно ли гарантировать непрерывность в физической памяти другими способами кроме hugepage?

Спасибо.

★★

Всё работает по логическим адресам. Насчёт того что ты описал про prefetch - я не в курсе правильно ли ты описал вообще что это, но если так, то вполне возможно он не работает через 4К-границы вообще. Если работает то тоже по логическим.

Про физическую непрерывность забей, она ни на что не влияет.

hugepage работают быстрее - у них в 1000 раз меньше метаданных на тот же объём данных.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Ну вообще если прямо кровь из носу нужна физически непрерывная, например для какого нибудь отлаживаемого устройства на шине, в ядре есть CMA (Contiguous Memory Allocator), правда я не помню он по умолчанию включён или нет.

Contiguous Memory Allocator allows other subsystems to allocate big physically-contiguous blocks of memory. CMA reserves a region of memory and allows only movable pages to be allocated from it. This way, the kernel can use the memory for pagecache and when a subsystem requests for contiguous area, the allocated pages are migrated away to serve the contiguous request.

Jameson ★★★★★
()
Ответ на: комментарий от firkax

hugepage работают быстрее - у них в 1000 раз меньше метаданных на тот же объём данных.

Но иногда они работают медленней. Для Qemu использовать transparent hugepages Oracle не рекомендует. Мои замеры показали, что да, с ними медленней.

Просто hugepages – мои замеры на Qemu показали, что особой разницы нет, чуть быстрее, но меньше 5% прирост скорости, а гибкости в управлении памятью сильно меньше получается.

PS: ТС, непрерывность больших кусков памяти это исключительно программисткая абстракций, для удобства написания кода, в реальности память состоит из кусков, да и она еще кусками в три уровня кеша проца попадает.

soomrack ★★★★
()

prefetch оперирует на адресах и блоках кратных какой-то степени двойки. Так что он либо никогда не сработает через границу страницы (если размер блока меньше 4 КБ), либо всегда будет это делать (если больше). Так что проблема неактуальна.

KivApple ★★★★★
()