По умолчанию в Linux на уровне операционной системы используется LRU кеш.
Подскажите, как можно изменить этот алгоритм на другой, более быстрый (но с более частыми промахами)? Например, кольцевой, когда новая память всегда выделяется последовательно. Или алгоритм с разбивкой памяти на 2 части, тоже с последовательной записью. В первой место закончилось — начали писать во вторую часть, а первую сделали устаревшей и очистили. И т.д.

Здравствуйте, prrt, Вы писали:

P>По умолчанию в Linux на уровне операционной системы используется LRU кеш.

Кеш чего? В ядре кешей очень много, и в большинстве LRU. Назовите подсистему, и посмотрим
естьли возможность перключения на какой другой.

Pagecache. Т.е. кеш, который чистится командой:
# sync && echo 1 | tee /proc/sys/vm/drop_caches

Еще один вариант, который меня бы вполне устроил — это отключить использование inactive_list. Т.е. не переносить страницы из active_list в inactive_list, а вместо этого сразу удалять.
Но тоже пока нигде не могу найти, как это сделать...

Здравствуйте, prrt, Вы писали:

P>Pagecache. Т.е. кеш, который чистится командой:
P># sync && echo 1 | tee /proc/sys/vm/drop_caches

Вообще для маппинга файлов, как вообще для чтения записи в файл, используются страничные
фреймы, описываемые структурой page, указатели на которые и сохраяются в кешах. Вот для
файлов таковым кешем является radix tree, которая входит в состав структуры address_space,
и которая входит в состав структуры file. Вот например обработчик page fault для отмапенного
файла.
Сначала ищется в кеше page-ов файла, если там не оказывается то
ищется так. То же самое происходит при чтении/записе данных в файл,
когда страничные фреймы используются для временного хранения перед или после копирований в страничные фреймы стороны, производящей операции.
Если рассмотреть последнюю функцию page_cache_read, то там имеется поиск страничного фрейма в системном пуле ядра, то же самое, например, в операции
записи . В обоих случаях, выделяется из системного пула __page_cache_alloc,
после чего struct page сохраняется в кеше файловой системы radix trie, и в swap кеше, который есть LRU.
В swap кеш они сохраняются для того, чтоб эти страничные фреймы, первыми очищались сбросом данных на диск, если свободных в системе не оказывается.
Этим занимается этот чувак
Изменить на другой нельзя.
А теперь по вопросу вопрос: свопинг фреймов на swap раздел это критичное сотояние для системы, наступает в исключительных случаях, значит
и вопрос о производительности этого LRU кеша, санет только в исключительных ситуациях, так зачем оно там навороченное, когда и LRU достаточно?

S>А теперь по вопросу вопрос: свопинг фреймов на swap раздел это критичное сотояние для системы, наступает в исключительных случаях, значит
S>и вопрос о производительности этого LRU кеша, санет только в исключительных ситуациях, так зачем оно там навороченное, когда и LRU достаточно?

Хм. Вообще говоря, swap раздела в системе просто нет. А вопрос возник по такой причине:
Есть машина, на которой крутится демон. Процессор загружен менее чем на 15%, загрузка по ядрам равномерная. Потребление памяти — процентов 5, всё остальное — system cache. Эти при максимальной нагрузке. Всё работает отлично без перезапусков месяцами, утечек паямяти никаких нет. Но в некоторые моменты времени (на нагрузке) мгновенно все ядра процессора нагружаются вплоть до 100% ядерными процессами типа migration, kswapd, softirqd и пр., продолжается это пару секунд. И дальше всё опять как обычно — загрузка проца максимум 15%, памяти — 5. Эти ядерные процессы иногда возникают одного типа, иногда другого, иногда все вместе.

После многих бессонных ночей, проведенных в поисках причины, решение всё-таки нашел: выполняю команду

# sync && echo 1 | tee /proc/sys/vm/drop_caches

и эти ядерные процессы исчезают и больше не появляются до тех пор, пока вся память снова не заполнится кешем. Была мысль прописать эту команду в крон, но всё-таки это костыль, да и первое время после очистки нагрузка сильная на диски идет.

Тогда может что-нибудь вы могли бы посоветовать, как в данной ситуации действовать?

Здравствуйте, prrt, Вы писали:

> Но в некоторые моменты времени (на нагрузке) мгновенно все ядра процессора нагружаются вплоть до 100% ядерными процессами типа migration, kswapd, softirqd и пр., продолжается это пару секунд. И дальше всё опять как обычно — загрузка проца максимум 15%, памяти — 5. Эти ядерные процессы иногда возникают одного типа, иногда другого, иногда все вместе.

kswapd уже сказал что такое, он будится для того, что перетряхнуть структуры page, какие скинуть на диск,
или провести работы по иерархическим спискам в массивах структур page.
softirqd исключительно важные потоки. Их по одному на каждый CPU в системе, и в их контексте
исполняются работы, связанные с тредовыми прерываниями, все таймеры управляются и отслеживаются в их контексте,
весь сетевой ввод/вывод производится в их контексте. При высоких сетевых нагрузках softirqd приводят
к неадекватному поведению пингвина, и вообще являются слабым местом и недостатком его сетевой подсистемы.
migration связан с перекидыванием исполнения тредов между CPU. Если на одном CPU
возникает лишняя нагрузка, он просыпается и разгружает его раскидывая task-и по остальным CPU.


P>

P># sync && echo 1 | tee /proc/sys/vm/drop_caches
P>

Когда делаете sync, просто оcвобождаете page-и, в которые были скопированы данные для записи в ФС,
но которые ещё не записались на диск. Можно посмотреть на опциии монтирования FS в /etc/fstab, опять
таки, что за FS, например очень похоже ведёт себя NFS на высоких нагрузках.

Ясно.
Файловая система ext4, из опций только acl и user_xattr. Как вариант, наверное, можно будет попробовать еще переустановить всё ПО с какой-нибудь другой файловой системой. Вот только долго и муторно это...