Если мы запускаем бинарь N раз, он N раз целиком загружается память (Y/N)?

Подозреваю, что да, что ядро пока не настолько хитровывернутое, чтобы смекать и экономить на таком, разделяя такие страницы памяти между независимыми процессами.

https://en.wikipedia.org/wiki/Kernel_same-page_merging

Ядро именно что настолько хитровывернутое. Если бинарь без релокаций или PIC/PIE, то секции кода и rodata совершенно точно будут просто замаплены в несколько процессов.

Разнообразные таблицы символов (динамические), всякие там GOT и PLT — это да. Стек и r/w данные — разумеется, тоже дублируются.

KSM тут не работает. В линуксе он включается специальным madvise()'ом; я уверен, что загрузчик ELF не помечает каждый загружаемый эльф как mergeable.

На самом деле реализовать такое поведение (и оно скорее всего реализовано) - проще простого. В исполняемом файле есть секции. Некоторые из них read-only (код, rodata). Их можно вообще без задней мысли маппить на одни и те же физические адреса. С data ситуация сложнее и в принципе можно их продублировать. Хотя если очень хочется экономить память и на этот случай есть решение - copy on write, который аппаратно умеют все нормальные процессоры (можно пометить страницу памяти как r/o, в итоге при попытке записи будет исключение, которое ядро может обработать копированием страницы в новое место и снятием r/o флага).

То есть банально оперировать флагами секций исполняемого файла и страниц в памяти. Никаких супер-пупер-эврестических алгоритмов нафиг не нужно.

Ещё есть такая фигня (не знаю как в Linux, но в Windows такое активно используется) - использование исполняемого файла в качестве файла подкачки. То есть r/o секции, если мало памяти, не выгружаются в обычную подкачку, а просто удаляются из ОЗУ. При необходимости загрузка происходит из исполняемого файла. Поэтому на офтопике exe-файл оказывается занятым, пока приложение работает.

Зачем это нужно? Нам известен путь к ELF + флаги секций. Можно при загрузке ELF, который уже запущен, просто не грузить R/O секции, а смаппить их на те же физические адреса, что и у первого файла. Освобождать память с помощью подсчёта ссылок (чтобы данные выгрузились только после завершения последнего экземпляра приложения). По идее алгоритм очень простой к реализации, оверхед (при запуске приложения столько всего происходит, пробежаться по списку уже загруженных файлов ничего не стоит, один счётчик для подсчёта ссылок тоже ничего не стоит) микроскопический.

использование исполняемого файла в качестве файла подкачки

Аж дух захватило! Это неиспользование подкачки для исполняемых файлов, а не использование исполняемых файлов в качестве подкачки.

Поэтому на офтопике exe-файл оказывается занятым, пока приложение работает.

В линуксе та же фигня. Но только сам файл, а не его место в иерархии ФС.

Для такого есть патч к ядру UKSM http://kerneldedup.org/en/projects/uksm/introduction/

Этот патч например есть в патчсете pf-kernel от post-factum

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

Не нужен тут никакой KSM, работает тот же механизм, что и при форке. Ядро отслеживает, что у него в page cache уже есть нужные страницы в неизмененном виде и просто мапит их в твое виртуальное адресное пространство.

Сначала они статически линкуют бинари, а потом героически преодолевают проблемы…

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

Давай, покажи её.

Не знаю как на счет подскачки, но перезаписать исполняемый файл во время работы нельзя - выдает Text file busy

N

Вот, поэкспериментируй:

(echo -n '"'; head -536870912c /dev/urandom | xxd -ps | tr -d '\n'; echo '"' ) > largeconstant.h

// q.c
#include <unistd.h>
#include <string.h>
const char *c =
#include "largeconstant.h"
;

int main(void) { strlen(c); sleep(10000); return 0; }

gcc q.c

for i in `seq 100`; do ./a.out &  done

Я почему-то такое не на всех бинарниках замечал. Хотя вот достоверно подтвердить сейчас не готов.

Это ты не мне рассказывай, а beastie — я прекрасно знаю, как это работает.

Вопрос был скорее про «хитровывернутость». И она таки есть.

А вот про мульти-маппинг rodata статически скомпелированных програм я не совсем уверен. В динамических это точно используется. И при форке память не дублируется.

Ну rodata нужно релоцировать? Так-то маппится по умолчанию всё, вне зависимости от того, где какая линковка, а уже потом если что-то где-то нужно отрелоцировать или пропатчить, то происходит CoW отдельных страниц.

Нет такой опции, я ошибся.

Насколько я знаю при запуске бинарь даже не сразу весь в память грузится, а по мере выполнения. Естественно все процессы одного бинаря используют общую память под код независимо от статической/динамической сборки. Страницы кода могут также выкидываться и читаться заново если свободной памяти мало.

man 2 mmap

Спасибо за модель для разбирательства.

Но что-то у меня подозрения, что бинарь таки не сто раз загрузился отдельно, либо он не стал целиком грузиться, иначе бы не хватило памяти. https://gist.github.com/andrey-utkin/1bf88af5800d03a20a64