Дисковый кеш Linux и kmalloc с GFP_ATOMIC - PullRequest
0 голосов
/ 26 декабря 2018

В известной статье есть такое утверждение о дисковом кеше Linux:

нет абсолютно никаких причин его отключать!


Также:

Исправная система Linux с более чем достаточным объемом памяти после некоторого времени работы покажет следующее ожидаемое и безвредное поведение:

  • свободная память близка к 0

  • используемая память близка к общему

  • доступная память (или «свободна + буферы / кэш»)имеет достаточно места (скажем, 20% + от общего числа)

  • используемый своп не изменяется

Эти условия выполняются вв моём случае и есть проблема.У меня есть некоторый рабочий сетевой код в режиме ядра, который должен распределять память в «атомарном» контексте (kmalloc() с установленным флагом GFP_ATOMIC).Таким образом, при высокой нагрузке, как и ожидалось, в то время как «свободная память близка к 0» мой код не может выделить память, и в конечном итоге он становится отказом в обслуживании.

Очевидно cron с sync && echo 3 > /proc/sys/vm/drop_caches не является решением из-за проблем с производительностью диска.Можно просто попытаться выбрать какой-то набор файлов, чтобы отключить кеширование, но это не кажется хорошим и надежным решением.

Вопросы:

  • Что такоеправильное и надежное решение в таком случае?(со стороны режима ядра, режима пользователя или обоих)
  • Почему считается, что нет причин отключать (уменьшать интенсивность) дисковый кэш?

Некоторые сообщенияэто мне не помогло: 1 и 2 .

...