Автор решил разобраться, почему утилиты btop и fastfetch показывают разную занятую память на FreeBSD. Всё оказалось хитрее, чем кажется.
Операционная система кэширует данные с диска в RAM — так всё работает быстрее. Этот кэш можно освободить, когда понадобится память. Именно из-за этого «сколько занято» — вопрос с подвохом. У каждой утилиты своя эвристика. fastfetch считает свободной память из очередей free + inactive + cache. btop — только free. Поэтому разница в показаниях громадная: в примере автора fastfetch показывал 82% занятой, а btop — всего 7%.
Но с btop оказалось ещё хуже. Он использовал 32-битные целые (u_int) для хранения размера памяти в байтах. Всё, что больше 4 ГБ, просто переполнялось. На машине с 5.7 ГБ btop показывал 422 МБ занятой, хотя реально было 4.42 ГБ. Кроме того, btop пытался считать кэш через vm.stats.vm.v_cache_count, но начиная с FreeBSD 12.0 этот параметр — просто заглушка, он всегда возвращает 0. Автор поставил десяток разных версий FreeBSD и проверил это лично.
Автор написал патчи. Он увеличил разрядность переменных, чтобы убрать переполнение, а для правильного подсчёта кэша начал вычитать размер ARC (кэша ZFS) из «закреплённой» (wired) памяти и добавлять обратно как кэш. Ещё он учитывает vfs.bufspace — кэш файловой системы, не связанный с ZFS. Патч htop уже приняли, а для btop пул-реквест пока висит без ревью.
В fastfetch автор предложил то же самое, но его пул-реквест сначала закрыли без комментария, а потом внедрили ту же логику, немного улучшив. Автор расстроился из-за отсутствия коммуникации, но рад, что код помог. Теперь он планирует разобраться с такой же проблемой для DragonFly BSD.
В итоге месяц изучения виртуальной памяти FreeBSD, десяток переустановок системы и три патча. Автор вспоминает, как в 14 лет пытался читать MINIX book и не понимал указатели на функции — а теперь сам копается в исходниках ядра. Он даже купил первое издание той книги, где 400 страниц занимает исходный код. На обложке написано «Unauthorized» — забавно.