Единственный совет, который я могу вам дать, это осторожное использование mlock () / mlockall () .. при поиске драйверов с ошибками.
Например, если гость Xen загружен с 1 ГБ, а затем увеличен до 512 МБ, очень типично, что привилегированный домен НЕ смотрел на то, сколько памяти паравиртуализированное ядро фактически обещало процессам (то есть Committed_AS). На самом деле, с Xen, если это значение не помещено в Xenbus, привилегированный хост не имеет представления о том, что будет делать такой воздушный шар. Я считаю, что это также совпадает с KVM, в зависимости от того, как настроено ядро .. но ваш вопрос предполагает, что мы ничего не знаем о таких вещах:)
Итак, защитите вещи (будьте осторожны, но осторожны), которые просто не могут быть выгружены, всегда учитывайте сценарий «небо падает».
Аналогичным образом, использование posix_fadvise () / posix_madvise (), чтобы сообщить ядру PV, насколько вы делаете или не нуждаетесь в буферизации, всегда хорошая идея.
Кроме того, вы мало что можете сделать ... поскольку вы говорите только с паравиртуализированным ядром, которое разработано так, чтобы процессы вообще не обращали внимания на виртуализацию.
Я не очень много использую KVM (пока), хотя планирую изучить его в будущем. Тем не менее, 90% того, что я пишу в последнее время, специально разработано для работы с паравиртуализированными гостями Xen. Извините, что немного ориентируюсь на Xen / C, но это мой опыт и pv_ops в основной строке (скоро также xen-0 ops):)
Хороший вопрос, кстати:)
Edit:
Когда я сказал «осторожный, но осторожный», я имел в виду один шаг выше консервативного. Если ваша программа выделяет некоторую структуру работы, которая нужна большинству функций, заблокируйте ее. Если вы выделяете буферы для чтения огромных файлов, не блокируйте их ... и обязательно вызовите posix_fadvise (), чтобы сообщить ядру, что вы собираетесь получить к нему доступ только один раз (если это так). Также не забудьте проконсультировать ядро о том, как вы используете файлы с отображением в памяти, особенно если они служат для организации параллелизма.
Короче говоря, помогите ядру вашего хоста управлять памятью, не позволяйте критически выделенным блокам попадать в грязную подкачку, не думайте, что ваша программа важнее всего, блокируя все, что она выделяет:)
Извините за двусмысленность. Лучшая фраза, которую я мог придумать, была «осторожная, но осторожная».