У нас есть набор приложений для Linux, который состоит из 3G общих библиотек с множеством различных внешних интерфейсов, которые загружают различные части общих библиотек. Мы работаем на машинах с 24G и часто загружаем большие части этого 3G. Мы думаем о том, чтобы заставить все 3G постоянно находиться в оперативной памяти, чтобы каждое приложение запускалось как можно быстрее.
Можно ли это сделать? Нашей первой мыслью было поместить двоичные файлы в виртуальный диск типа / dev / shm, но похоже, что тогда ядро будет свободно обмениваться содержимым, что нам не нужно. Мы могли бы уменьшить параметр swappiness до 0, но я не думаю, что мы этого тоже хотим, потому что файловые кеши - это хорошее использование памяти. Мы просто хотим диктовать, что этот конкретный кусок материала должен постоянно оставаться горячим.
Есть системный вызов mlock, который звучит именно так, как мы хотим, но я не уверен, как интегрировать это с виртуальным диском.
Может быть, нам вообще не нужен ramdisk, а процесс демона, который просто отображает полный экстент каждого двоичного файла, передавая MAP_SHARED, MAP_LOCKED и MAP_POPULATE? Приведет ли это к будущим нагрузкам других процессов для немедленного доступа к той же физической памяти? Правильно ли, что ld загружает разделяемые библиотеки, используя mmap с MAP_SHARED?
Любые указатели приветствуются! Также любые замечания о том, почему это хорошая идея.