Я не уверен, что полностью и правильно понял смысл предыдущего сообщения, поэтому лучше расскажу поподробнее моё видение этого вопроса/проблемы - тогда, возможно, и мне и всем станет яснее из-за чего возникает проблема и каких изменений можно ждать от патча который я предложил выше.Начнём с того, что при работе с файлами rtorrent (libtorrent) активно использует системные вызовы mmap/munmap т.е. программа "отражает" файл в память.
Использование этих системных вызовов имеет несколько особенностей. Одна из них - при множественных запросах на отражение одного участка файла (как в рамках одного процесса, так и в случае с различными процессами) возможно (при определенных условиях) ограничиться всего одной "копией" файла в памяти. В определенных случаях это приводит к многократной экономии памяти.
Следует заметить, что память, "в которую" производится чтение mmap-ed файла явно не соотнесена с процессом, который выполнил системный вызов mmap (т.е. она не считается "памятью только этого процесса"). Именно по этой причие после вызова mmap можно заметить, как объём active памяти увеличивается, но rss процесса (rtorrent) не изменяется.
Почему так происходит? - Отчасти потому что данное "отражение файла в памяти" может использоваться другими процессами.
Что происходит когда выполняется munmap? - Грубо говоря "количество ссылок" на участок памяти, хранящий "отражение файла в памяти" уменьшается. Но этот участок памяти всё ещё относится к Active пулу. И он будет очищен только когда в следствии "vm pressure" операционная система начнёт искать участки памяти которые безболезненно можно освободить (за счёт наличия их в backing store). В данном случае "отражение файла в памяти" плюс сам файл (на физическом носителе) и будут представлять "участок памяти, который может быть освобождёт" плюс его backing store.
**
Небольшое отступление для тех, "кому очень интересно" - попробуйте скачать хотябы двухсотмегабайтный файл при помощи rtorrent, далее обратие внимание на состояние памяти, потом удалите файл (или отмонтируйте раздел, куда файл был скачан) и посмотрите на то, что произойдёт с Active в следующие 30 секунд.
**
Таким образом получается, что при использовании mmap/munmap для отражения файлов в память, размер active пула будет рости до тех пор, пока не возникнет своего рода "событие нехватки памяти" и vm не начнёт выполнять ревизию страниц памяти active пула.
Что происходит при использовании данного патча - при помощи вызова msync
мы указываем, что участок памяти (который мы собираемся "освободить") необходимо считать "недействительным" отражением файла. За счёт этого после вызова munmap участок памяти попадает во free пул.
Всё это значит, что с этим патчем:
- при использовании rtorrent не должен происходить постоянный/неконтролируемый/необъяснимый рост active памяти. Но объём active память может увеличиваться в момент когда происходит проверка хэша, или когда вы раздаёте/качаете файлы для/у значительного количества пиров. Т.е. если, например, 100 пиров качают у меня 100 различных фрагментов файлов, в раздачах, где chunk size равен 1Мб, то размер Active памяти увеличится на 100Мб.
- как только rtorrent закончил отдавать или качать определённый фрагмент файла он вызывает unmap, а значит сразу же освобождается и Active память
- после выхода из программы все участки памяти, которые rtorrent запрашивал у ОС для "отражения файлов в памяти", попадут во free pool
Примечание №1: для того, чтоб детально не описывать возможные режимы работы mmap/munmap я ограничивался фразами типа "существуют режимы работы" или "в определённых случаях".
Примечание №2: всё вышесказанное демонстрирует уровень моей некомпетенции в понимании вопросов работы виртуальной памяти :) Т.е. на самом деле всё может быть совсе не так, как это понимаю я :)
