Во-первых, позвольте мне сказать, что если вы собираетесь принимать какие-либо политические решения (я должен продолжить эту операцию?) На основе этой информации, STOP . Как указывал WGW, здесь неизбежны гонки; память может быть использована между проверкой и использованием. Просто проверьте наличие ошибок в распределении памяти и найдите соответствующий путь отказа. Более того, если вы запрашиваете память, когда не хватает свободной памяти, часто ядро может получить больше свободной памяти путем очистки различной кэш-памяти, подкачки на диск, освобождения дисков и т. Д. И фрагментация памяти ядра может дать сбой (много страниц) выделения, когда они не выполняются через vmalloc даже при большом количестве свободной памяти.
Тем не менее, есть API для запроса доступности памяти ядра. Следует отметить, что ядро имеет несколько пулов памяти, поэтому даже если один из этих API говорит, что у вас нет свободной ОЗУ, возможно, она доступна в интересующем вас пуле памяти.
Во-первых, у нас есть si_meminfo . Это вызов, который, помимо прочего, предоставляет данные о доступности для /proc/meminfo и сообщает о текущем состоянии распределителя страниц собеседника. Обратите внимание, что кэшированный и буферный баран можно очень быстро преобразовать в свободный баран.
global_page_state(NR_SLAB_RECLAIMABLE) также может быть использован для подсчета того, сколько памяти памяти можно быстро восстановить. Если вы запрашиваете распределение, эта память может и будет освобождена по требованию.
Распределитель SLUB (используемый для kalloc() и т. П., Среди прочего) также предоставляет статистику для своих внутренних пулов памяти, которая также может отражать свободную память в каждом пуле памяти. Это может быть недоступно для того же API в зависимости от того, какой распределитель выбран в вашей конфигурации - пожалуйста, не используйте эти данные, кроме как для отладки . Соответствующий код (реализующий /proc/slabinfo) можно найти в mm / slub.c