На самом деле, то, что вы описали, сбивает с толку раздувание и «слияние одной и той же страницы». Я попытаюсь уточнить эти два, чтобы сделать различие очевидным.
Вспышка памяти
Это хитрость, чтобы убедиться, что часть памяти, выделенной гостевой виртуальной машине, может использоваться другим гостем или самим хостом (кешами и т. Д.). Это делается следующим образом:
В гостевое ядро внедряется драйвер, который отслеживает использование гостевой памяти и «крадет» часть неиспользуемой памяти (выделяя ее для себя в пространстве гостевой памяти, таким образом следя за тем, чтобы ничто на этом госте не могло коснуться этого диапазона).
Затем он информирует ядро хоста о том, что он может фактически удалить эти страницы памяти из ядра, что они не будут использоваться в гостевой системе (до тех пор, пока гость не испытывает некоторое давление памяти, после чего всплывает всплывающее окно, и используется эти диапазоны снова).
В конечном счете, ядро может выделить ту же самую память другому гостю и сделать использование всей памяти намного более эффективным. если гости работают с большим количеством свободной памяти.
Слияние одной и той же страницы
Этот метод идентифицирует идентичные страницы памяти, которые по какой-то причине еще не помечены как «квази-только для чтения» с копией при записи, и помечает их как таковые.
Теперь на уровне ОС существует ограниченная потребность в подобных хитростях. Проще говоря, в большинстве случаев, когда у вас есть идентичные страницы памяти, они уже доступны только для чтения (иногда даже без 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