Про изменение поведения free между procps 3 и procps 4

Linux kernel 6.1+ memory used ~80%

В той теме больше про то, что ядро теперь по-новому память считает. Но тут дело не только в ядре. Я выше привёл сравнение выводов двух разных версий free на одном ядре, версия которого 6.6.64.

Старая версия free показывает меньше «used» памяти в тех же самых обстоятельствах, где новая версия показывает больше.

теперь ты можешь запартнёриться с тем ТС-ом в своих изысканиях ))

А strace какое-нибудь различие показывает?

А strace какое-нибудь различие показывает?

Конечно. Там и в исходниках разница видна.

Я просто не мог понять что жрёт у меня память.

Вот залогинился я в FVWM, кроме эмулятора терминала ничего не запущено, а free мне сразу показывает, что больше гига памяти уже used. Вот как это так?

Переключаюсь в ядерную консоль, выключаю иксы, очищаю кэш файлов... free всё равно показывает, что больше гига RAM used.

Складываю память запущенных процессов - получается меньше чем 300 Мб. В tmpfs'ах меньше чем 40 Мб суммарно, в файловом кэше тоже столько нет...

В итоге и додебажился, что это теперь новая логика такая, а старая версия free выдаёт как раз ожидаемый результат.

Дополни, плиз, выводом

$ free -V

Изменения, по ходу, произошли между procps 3 и procps 4.

Выше я сравнивал версии free из procps-3.3.17 и procps-4.0.4.

Надо сравнить с uutils-procps

Надо сравнить с uutils-procps

Показывает также как и procps-4.0.4. free из procps-3.3.17 показывает меньше used RAM.

А чё за дистрибутив такой у вас?

63314 + 652  < 64231
63313 + 1238 > 64231

Может быть, сборщик вашего дистрибутива ушёл на новогодние каникулы. Или в вашем дистрибутиве произошла смена поколений программистов, и у нового поколения программистов иные взгляды на арифметику при подсчёте объёма памяти. Дистрибутив какой? Чтоб случайно не вляпаться, народ в моём лице желает знать.

не всем нужна стабильность поведения

1) Раньше в «used» буфера и кэши не учитывались (в т.ч. об этом и пишу). 2) Это также особенности free из procps 4: https://gitlab.com/procps-ng/procps/-/issues/334 .

Update to high version, problem in some scenarios:

used is larger used + free > total, it seems unreasonable

What we don't want to do is replace a known wrong answer with another known wrong answer. We can say that Available is wrong, if it is less than Free. However substituting that answer with one of the suggested ones (which we have had before) just gives us a different but also wrong answer.

The kernel should be giving us the right answer but to diagnose that we'll need more data.

Т.е. чуда не произошло? Что 652, что 1238 не имеют никакого значения.

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

Классическая арифметика free: used = total - free - cached - buffers.

Теперь free выводит другое ближе к total - free.

Ну значит так и есть, кушает и не стесняется. free он же не на голом месте, а берет данные из /proc/meminfo

Вот уж действительно! Когда ядерные хакеры внедряют в своё свежее изделие проплаченный функционал, а мальчики на подтанцовках (сочиняющие всякую лабуду вроде утилиты free) начинают терять навыки арифметики, потому что становится невозможным сложить два плюс три, то 300-600 m памяти на пользовательских комп-ах не имеют никакого значения. Будто бы эти пользователи могут как-то повлиять на чудесатые процессы. Не могут. Поэтому - не имеет значения.

Новый вариант не слишком то адекватен.

Задачка решена! Землекопа полтора. (с) Когда складываешь два целых числа не торопись дать ответ, сначала выслушай мнение других, более авторитетных деятелей (Автор утилиты free)

Че теперь под линем стало как в NetBSD - приборы совсем погоду показывают?

Суровый мир юникс-лайка как обычно.

used Used or unavailable memory (calculated as total - available)
man free

Это свежие маны, их уже переписали.

ЗЫ. Я помню времена, когда man rand.3 советовал делать так:

int get_random (int g_rand_max)
{
  return (int) ((g_rand_max + 1.0) * rand() / (RAND_MAX + 1.0));
}

проплаченный функционал

Заявил анон, не отличающий функционал от функциональности.

выхлопы двух разных free

офигеть они free поломали! почти в два раза больше выжратой памяти теперь показывает на ровном месте! это же абсолютно неадекватно, придется теперь через htop смотреть

Что 652, что 1238 не имеют никакого значения.

обоснуй

Не обращайте внимания, разговор сам с собой.

Че теперь под линем стало как в NetBSD - приборы совсем погоду показывают?

а ты через что показатели памяти в netbsd смотрел? vmstat?

Ты написал

Теперь free выводит другое ближе к total - free.

Я уточнил, что

total - available

Ну и раз уж мы тут предаёмся воспоминаниям, то

Классическая арифметика free: used = total - free - cached - buffers.

не такая уж «классическая», появилась лет 10 назад и ты тогда тоже тему создавал по этому поводу: Последние Debian'ы и кэш в RAM

До этого было как раз total - free.

кстати, линуксовый vmstat -S M -s сейчас показывает то же, что и free -m

и ты тогда тоже тему создавал по этому поводу

Там как раз начинались поползновения в сабжевом направлении, а не наоборот. Т.е. до этого в used числа были ещё меньше.

Кто они? Там один чувак, походу, ранее уработавший dropbox, ваяет. Только он сам вахуе, поэтому не может ничиво объяснить по теме полученных значений в числах. Так и пишет, подлец, чтоб я по этому поводу ни о ветил - всё брехня, давайте-ка не задавайте мне вопросов, а поспрашайте авторов ядра. Вон, выше в обсуждении аж зацитировали классика.