LINUX.ORG.RU

mmap нескольких участков одного файла


0

1

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

Вопрос, что более Ъ - под каждый mmap создавать свой дескриптор файла, или можно обойтись общим? И насколько вообще это работоспособно (пока интересует только чтение данных, но в будущем возможна и запись)? Какие тут могут быть подводные камни?

★★★★★

Можно обойтись общим дескриптором. Подводные камни - если файл большой и мапируется почти целиком, хоть и по кусочкам, то на 32-битной системе может не хватить адресного пространства процесса.

Sorcerer ★★★★★ ()

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

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

Вообще я хочу мапнуть ее много раз, и пока только читать... но если писать, то в разные места страницы.

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

но если писать, то в разные места страницы

Вот я об этом и говорю. Ты-то пишешь в разные места, а синкается страница целиком.

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

А они синкаются? Или это будет физически одна страница?

Вот в этом и вопрос. В линуксе фокус работает, ничего не конфликтует. Формулировки в мане не вселили в меня полной уверенности, что так и должно быть всегда.

const86 ★★★★★ ()

Интересный вопрос. Выскажу предположение. Множество участков виртуальной памяти отмапенных(?) с одной общей области файла будут ссылаться на один и тот же участок физической памяти, где будет лежать страница дискового кэша. Ну то есть любые изменения в виртуальной памяти будут менять один и тот же кусок физической памяти. Если не будет никаких фокусов с когерентностью процессорного кэша, то все вообще должно работать идеально.

Кто хорошо разбирается в таких вещах, может сказать - насколько верно мое предположение?

pathfinder ★★★ ()

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

tailgunner ★★★★★ ()

Вопрос, что более Ъ - под каждый mmap создавать свой дескриптор файла, или можно обойтись общим?

Да, и в догонку к вышесказанному. Ъ путь по идее должен быть «обойтись общим дескриптором».

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

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

Так все-таки я ошибаюсь и разсинхронизация в принципе возможна?

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

Так все-таки я ошибаюсь и разсинхронизация в принципе возможна?

Я думаю, что при записи в разные отмапленные области будут созданы разные страницы; соотвественно, при записи в backing store имеем непонятно что.

tailgunner ★★★★★ ()

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

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

С чтением понятно, всем большое спасибо!

С записью я так понимаю, что пересекающиеся страницы после записи надо принудительно синхронизировать (тому кто пишет) а всем читающим обновлять? Дела... пока забью на это хозяйство, будет readonly.

AIv ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.