LINUX.ORG.RU

Вопрос про mmap() файлов в память.

 


0

2

Предположим у меня есть файл большого размера с данными в некоторой древовидной структуре.

Необходимо в режиме read only иметь быстрый случайный доступ к разным узлам дерева, но при этом не хотелось бы, что процесс отъедал много реальной оперативной памяти, так как есть другой процесс, которому она нужна. Думаю замапить весь файл в память с помощью функции mmap().

Правильно ли я понимаю, что ОС будет автоматически подгружать в память странички по мере чтения и только те, к которым обратились? И выгружать те странички, которыми давно не пользовались, если физической оперативной памяти на всех не хватает и она нужна другому процессу.

Или я слишком много хочу от ОС?

Правильно ли я понимаю, что ОС будет автоматически подгружать в память странички по мере чтения и только те, к которым обратились?

Нет. ОС будет умничать - например, если ты последовательно обратился к нескольким смежным страницам, она наверняка сделает readahead.

И выгружать те странички, которыми давно не пользовались, если физической оперативной памяти на всех не хватает и она нужна другому процессу.

Да, ОС будет это делать.

tailgunner ★★★★★ ()

Будет медленней, чем если просто руками читать, что нужно. Если по дереву ходить очень активно, то с mmap вообще кататония наступит.

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

Нет. ОС будет умничать - например, если ты последовательно обратился к нескольким смежным страницам, она наверняка сделает readahead.

Не сделает, если предварительно пометить регион как MADV_RANDOM

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

ОС будет умничать - например, если ты последовательно обратился к нескольким смежным страницам, она наверняка сделает readahead.

Не сделает, если предварительно пометить регион как MADV_RANDOM

man madvise

«The kernel is free to ignore the advice.»

Кроме того, у ядра наверняка есть и другие способы умничать. Гарантий нет,

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от ttnl

Закладывайся на детали реализации

/fixed

Я помню, как юзеры пытались возмущаться «вы изменили поведение, так не честно!!!11», и то ли Линус, то ли Алан им объясняли: «поведение соответствует спеке, правьте свои программы».

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Закладывайся на детали реализации

LOL. Единственная функция MADV_RANDOM — препятствование RA. Предупреждение о необязательности исполнения, которое ты видишь в man, — для домохозяек, которые рискнут использовать этот флаг на устройствах, где он в принципе не поддерживается. Широко задокументирован. Не говори глупость, короче

ttnl ★★★★★ ()

Выбираешь между mmap vs read или mm vs direct read?

В первом случае и то, и другое оседает в кэше страниц, и то, и другое вызывает reclaim. Путь от обработки page fault до получения страницы примерно такой же, как и при обычном read. Разница минимальна.

Второй способ с direct read тебе не подходит, так как ты не получишь преимущества от повторного чтения одинаковых страниц (не будешь же ты заниматься кэшированием в userspace).

Я бы попробовал mmap. Думаю, принципиальной разницы не будет.

Также могу посоветовать засунуть файл в сжатый раздел в оперативной памяти, если влезет.

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

В первом случае и то, и другое оседает в кэше страниц, и то, и другое вызывает reclaim. Путь от обработки page fault до получения страницы примерно такой же, как и при обычном read. Разница минимальна.

Забыл про обход развесистой mm_struct и TLB poisoning. Выстрелит при рандомном доступе на большом диапазоне адресов.

Второй способ с direct read тебе не подходит, так как ты не получишь преимущества от повторного чтения одинаковых страниц (не будешь же ты заниматься кэшированием в userspace).

На NVMe может быть уже наоборот.

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

Забыл про обход развесистой mm_struct и TLB poisoning. Выстрелит при рандомном доступе на большом диапазоне адресов.

Несколько load'ов — это крохи по отношению к работе с диском и объемам прогоняемых данных. Все кэши будут со страшной скоростью мыться полезной нагрузкой. Доля работы с таблицей страниц будет меньше погрешности измерений.

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

Предупреждение о необязательности исполнения, которое ты видишь в man, — для домохозяек

Как скажешь. Я помню как минимум один случай, когда выгоднее быть домохозяйкой, чем читателем кода.

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

Дреппер это был. В сраче про memcpy и перекрывающиеся регионы.

Нет. Срач с Дреппером о memcpy и сломе flash-плагина - это было недавно. А то, о чем я говорю, было давно. И там был не истеричка Дреппер, а кто-то из героев былых времен.

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

то ли Линус, то ли Алан

Дреппер это был.

не Дреппер, а кто-то из героев былых времен.

Я знаю, твой год - он всего от зари до зари...
Мне тысяча лет, потому лишь что мне тридцать три.
(Ю. Кукин, 1965)
ABW ★★★★ ()
Ответ на: комментарий от ttnl

Несколько load'ов — это крохи по отношению к работе с диском и объемам прогоняемых данных. Все кэши будут со страшной скоростью мыться полезной нагрузкой. Доля работы с таблицей страниц будет меньше погрешности измерений.

Кэш не успеет вымыться до того, как TLB падёт. Особенно хорошо заметно, если железо не самое свежее (Ivy Bridge и древнее).

Я сетевой блочный девайс написал, упирается в 50 GbE сеть, а, линейно экстраполируя, в CPU упрётся где-то за 200 GbE. Это уже скорости младших DDR3. Диски очень быстрые нонче.

mv ★★★★★ ()