— Замечаем, что свободная память куда-то внезапно съёбывается. killall -STOP firefox-bin
— Уходим с воркспейса с браузером. Память возвращается. Firefox всё ещё в T state.
— Возвращаемся в предыдущий воркспейс. Память опять куда-то девается.
— Дампим smaps_rollup всех процессов, сравниваем. Разница копеечная. Неважно, Rss, Pss, firefox-bin, Xorg, i3 — да вообще всех метрик и по всем процессам.
— Дампим meminfo. Разница только в гигабайтищах, на которые похудели MemFree и MemAvailable. slabinfo и df -h /dev/shm на таком фоне даже нет смысла сравнивать (но всё равно сравниваем и не видим ничего интересного).
Что, бля, происходит нахуй?!
Цоперайт © 2010-2016 @stiletto.
https://lxr.missinglinkelectronics.com/linux/mm/page_alloc.c#L5773
https://lxr.missinglinkelectronics.com/linux/+ident=115735849
https://lxr.missinglinkelectronics.com/linux/+ident=99232837
https://lxr.missinglinkelectronics.com/linux/+ident=118983860
Если у тебя NUMA или 32-битная система, то, вероятно, память может почему-то менять формальный тип в зависимости от того, в какую зону она попадает (есть она в текущих таблицах трансляции, или нет). А так любой кусок кода менеджера памяти может по своему разумению циферку взять и переписать.
Более вероятно, что у тебя либо процессы пихаются в какую-то cgroup в зависимости от видимости на экране, либо реально на SSD мгновенно сбрасывается всё изменённое содержимое страниц, и они помечаются свободными.
@enterprize Вариант А: запись в ядре выдаёт просто выдаёт последнюю записанную циферку, кто бы и с какими целями бы её ни поменял. Возможно, какой-то кусок менеджера памяти ради простоты переводит все страницы какой-то категории в свободно выкидываемые, зная, что уже при следующем переключении планировщика активность процесса или обработка переключения контекстов восстановит нужное, а тут процесс стоит. Тогда что-то похожее должно наблюдаться и с другими нормально работающими программами, если их притормозить.
Вариант Б: i3 для не выводимых на экран окон WM_STATE задаёт в withdrawn. Вероятно, X-сервер при этом помечает какие-то ресурсы и буферы как более не нужные (или, возможно, им вызываются какие-то callback'и в GDK или в прочих используемых Firefox прокладках). Если где-то между приложением и X-сервером происходит утечка памяти, эти страницы могут попадать в произвольные списки, и X-сервер может вызывать совершенно бессмысленные функции менеджера памяти для произвольных указателей внутри общего выделенного пространства. Вероятно, только отсутствие необходимости возврата страниц в систему спасает тебя от мгновенного segfault, и если специально сожрать тестовой программой «свободную» память в момент похудения, всё рухнет после разморозки работы.