Выполняет ли Linux "оппортунистическую замену" или это миф?
По умолчанию с etckeeper/etcявляется репозиторием git, поэтому вы можете использовать инструменты git для просмотра его содержимого (и изменений ). Например, вы можете использоватьgitk(после его установки )для просмотра истории репозитория, а если вы хотите сосредоточиться на конкретном файле, вы можете указать его в командной строке:
cd /etc
gitk apt/sources.list &
Поскольку вы являетесь пользователем KDE,qgitможет показаться вам более удобным.
Нет, в Linux нет такой вещи, как оппортунистический обмен. Я потратил некоторое время на изучение проблемы, и все источники (учебники, электронные письма в списках рассылки разработчиков ядра, исходный код Linux и комментарии к коммитам, а также некоторые переписки в Твиттере с Мелом Горманом )говорят мне о том же. :Linux освобождает память только в ответ на некоторую форму нехватки памяти (за очевидным исключением гибернации ).
Все популярные заблуждения на эту тему, вероятно, происходят из того простого факта, что Linux не может позволить себе ждать, пока не освободится последний байт памяти, прежде чем начинать подкачку. Ему нужна некоторая подушка, чтобы защитить его от экстремальных форм истощения памяти, и есть некоторые настраиваемые параметры, которые могут повлиять на размер этой подушки (, например.vm.min_free_kbytes). Но это не то же самое, что «обменять, потому что больше нечего делать».
К сожалению, алгоритм рекультивации фреймов страниц стал намного сложнее по сравнению с версией 2.6 (, когда он был подробно описан в книге Мела Гормана ), но основная идея примерно та же :рекультивация страниц. запускается неудачными выделениями, которые затем либо просыпаются kswapd, либо пытаются синхронно освободить страницы (в зависимости от нехватки памяти, флагов выделения и других факторов ).
Наиболее очевидная причина, по которой выделение страниц может начать давать сбой при наличии достаточного количества свободной памяти, заключается в том, что они могут запрашивать непрерывную память, в то время как в действительности память может быть слишком фрагментирована для удовлетворения запроса. Исторически сложилось так, что разработчики ядра Linux пошли на многое, чтобы избежать необходимости в непрерывном распределении памяти. Тем не менее, некоторые драйверы устройств по-прежнему требуют этого --либо потому, что они не могут выполнять многостраничный ввод-вывод в память (, разбрасывать -, собирать DMA ), либо это может быть просто небрежное кодирование разработчиками драйверов. Появление Transparent Huge Pages (THP )послужило еще одной причиной выделения памяти физически смежными блоками.
Уплотнение зон, введенное примерно в то же время, должно помочь решить проблему фрагментации памяти, но оно не всегда дает ожидаемый эффект.
Существуют различные vmscanточки трассировки, которые могут помочь понять, что именно происходит в вашем конкретном случае. --Всегда проще найти то, что вам нужно, в коде ядра Linux при наличии определенных стеков вызовов, чем просто сканировать все подряд. выглядит отдаленно актуальным.