Поясните про контейнеры

Каждый свою копию.

По умолчанию каждый свою копию. Если хочешь сэкономить - юзай UKSM(обычный KSM не подойдет)

гм. Как бы посмотреть на возможный объем дедуплицированной памяти в конкретном случае?

Вкорячивать такие патчи без уверенности в их эффективности как-то не хочется.

Нет ли утили которая показывает суммарное число страниц физической памяти используемой несколькими процессами?

Как я понимаю, форкнувшиеся процессы явно будет иметь кучу общих страниц кода. А если это параллельно запускаемые процессы?

В случае дискового кэша, полагаю, это зависит от того как организовано хранилище контейнеров. Если /some/file в контейнере 1 и /some/file в контейнере 2 соответствуют одному и тому же набору блоков на блочном устройстве то и в дисковом кеше дублирования не будет. Есть разные способы достижения такой дедупликации: использование одной базовой ФС для нескольких контейнеров, дедупликация на уровне файловой системы, наверное ещё что-то есть что с ходу не вспоминается

Если /some/file в контейнере 1 и /some/file в контейнере 2 соответствуют одному и тому же набору блоков на блочном устройстве то и в дисковом кеше дублирования не будет. Есть разные способы достижения такой дедупликации: использование одной базовой ФС для нескольких контейнеров, дедупликация на уровне файловой системы, наверное ещё что-то есть что с ходу не вспоминается

Не всегда.

Если используется дедупликация на уровне ФС (btrfs, zfs) или соответствующий storage driver, то page cache будет распухать.

Дедупликации на уровне ФС нет, в том то и вопрос

Ну во-первых, например eve-ng такие патчи использует, что уже намекает о том, что они что-то подозревают(но у них там задача специфическая - пачки виртуальных роутеров стартовать с одного образа).

Вкорячивать такие патчи без уверенности в их эффективности как-то не хочется.

Тесты в Интернете есть, гугл в помощь.

Как бы посмотреть на возможный объем дедуплицированной памяти в конкретном случае?

в каком именно? в разрезе конкретного процесса - хз, в разрезе по всей системе - примерно там же, где и KSM(т.к. UKSM - это патч на классический KSM) - в /sys/kernel/mm/uksm/pages_shared

На продакшен мне тоже такие патчи натягивать ссыкотно(там где их нет из коробки, см. eve-ng), на рабочем десктопе гоняю уже вторую неделю - проблем не выявил, потребление памяти упало незначительно:

pinkbyte@oas1 ~ $ cat /sys/kernel/mm/uksm/pages_shared 
10947

в /sys/kernel/mm/uksm/pages_shared

Отлично.

Пичалька. Патч для 4.14 режектится на 4.14.251 :(

Хорошо, что есть https://elixir.bootlin.com/

Примерно год назад переписали кусок кода в mm/memory.c, а патч датируется «2017-02-26 UKSM 0.1.2.6»

В районе 4.14.150 оказался код на который расчитан uksm-патч. Хорошо, что логика изменений понятна.

https://gitlab.com/post-factum/pf-kernel/-/commits/ksm-5.15/

Лучше так.