Раздувание памяти в ОС

13

Некоторые гипервизоры оптимизируют использование памяти с помощью метода, который называется «всплывающим списком» (по крайней мере, так его называет KVM), этот метод дедуплицирует память между виртуальными машинами и устанавливает общие страницы только для чтения с копированием при записи.
Это своего рода противоположность вызова вилки.

Реально ли реализовать на уровне ОС для процессов (я думал в основном о дублировании памяти при просмотре с помощью Chromium с несколькими вкладками на одном сайте), уже реализовано ли это?

Диди Коэн
источник

Ответы:

14

На самом деле, то, что вы описали, сбивает с толку раздувание и «слияние одной и той же страницы». Я попытаюсь уточнить эти два, чтобы сделать различие очевидным.

Вспышка памяти

Это хитрость, чтобы убедиться, что часть памяти, выделенной гостевой виртуальной машине, может использоваться другим гостем или самим хостом (кешами и т. Д.). Это делается следующим образом:

В гостевое ядро ​​внедряется драйвер, который отслеживает использование гостевой памяти и «крадет» часть неиспользуемой памяти (выделяя ее для себя в пространстве гостевой памяти, таким образом следя за тем, чтобы ничто на этом госте не могло коснуться этого диапазона).

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

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

Слияние одной и той же страницы

Этот метод идентифицирует идентичные страницы памяти, которые по какой-то причине еще не помечены как «квази-только для чтения» с копией при записи, и помечает их как таковые.

Теперь на уровне ОС существует ограниченная потребность в подобных хитростях. Проще говоря, в большинстве случаев, когда у вас есть идентичные страницы памяти, они уже доступны только для чтения (иногда даже без CoW), поскольку в основном это код приложения, библиотеки и т. Д. Они изначально открываются через карту памяти, и, таким образом, ядро ​​может сохранять только одна их копия в ядре (если она вообще есть, она также может полностью выгружать ее и разрешать выгружать из основного хранилища по мере необходимости).

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

Именно поэтому он может время от времени сканировать всю систему одинаковых страниц памяти - большая часть времени, они будут идентичны по гостевой ОС, а не для каждой - гостевое ядро ​​делает достойную работу, поддерживая объем памяти в пределах своего диапазона. Таким образом, в типичной среде виртуальных машин, где одно ядро ​​хоста обрабатывает более 50 гостей, экономия памяти может быть довольно значительной.

Оба сразу

Воздушные шары и Same-Page-Merging могут сосуществовать очень хорошо, достигая довольно существенного перерасхода памяти для идентичных систем.


Чтобы ответить на ваш вопрос - Same-Page-Merging может и иногда включается на уровне ОС. Это связано с совместным использованием страниц, которые интерпретируются и, следовательно, могут оказаться идентичными без наличия одного и того же файла поддержки.

В вашем примере Chromium - сами двоичные файлы процесса уже дедуплицированы с помощью карты запуска только для чтения - они совместно используют одно и то же пространство памяти. Кэши страниц (содержимое вкладок) обычно также распределяются между процессами (копирование при записи только для чтения) благодаря способу управления дисковым кешем - один и тот же файл на диске может быть открыт одновременно между различными процессами в виртуальной машине. Оптимальный смысл.

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

Это отличается в мобильных системах. Например, Android широко использует KSM для дедупликации идентичного кода между различными приложениями.

В любом случае вы можете включить его самостоятельно в Linux (Kernel SamePage Merging). Драйвер экспортирует различные статистические данные, которые после прочтения этого ответа вы сможете интерпретировать и сами принять решение, подходит ли оно для ваших целей.

https://www.kernel.org/doc/Documentation/vm/ksm.txt

qdot
источник
3
Слияние на одной странице также называется «трансцендентной памятью», в зависимости от гипервизора (и его возраста).
Тим Пост
Спасибо, я вижу, что KSM требует, чтобы приложение знало об этом, и из (быстрого) поиска Chromium не поддерживает его на данный момент. Я знаю, что двоичные файлы дедуплицированы, но я в основном имею в виду вывод JIT и необработанные сценарии, которые сильно нагружают мою оперативную память ...
Необработанные сценарии в Chromium также дедуплицируются - они помещаются в дисковый кеш, как и во всех других веб-объектах, и дисковый кеш отображается, а не читается.
qdot
Необработанные сценарии отображаются, но даже обычные сценарии (такие как jQuery и Angular.js) реплицируются в кеше и не сопоставляются друг с другом, поскольку на различных серверах сайта интенсивно используются CDN и точные копии файлов сценариев.
Это, вероятно, должно закончиться в чате, но я бы хотел видеть вашу статистику из Linux KSM.
qdot