Доколе мы будем терпеть морально устаревший swap не позволяющий использовать свопа более 2.5 от объёма ОЗУ?

В конце 2020 патч отозван из небытия, доработан и протестирован, обзавелся своей репой и потихоньку включается в сборки ядер типа pf и xanmod. Впереди - предложение в LKML. Если у меня будут силы, то надеюсь отправить летом патч в linux-mm.

Хорошо. А допустим, приспичит мне наложить этот патч в «арче» на RT-ядро, это возможно, или какие-то подводные камни будут? И как этими OOM-killer-ами пользоваться? Удивительно, но за все годы "корчинга" как-то не интересовался темой.

C RT проблем быть не должно. С PREEMPT проблем нет. Алгоритм патча предельно прост. Обратите внимание на возможные проблемы с DRM/i915.

И как этими OOM-killer-ами пользоваться?

Киллер сам приходит когда нужно, демо скидывал.

Выгружать неиспользуемые данные в своп. Сколько у себя не проверяю, в свопе ровно нуль.

Тут чаще жалуются на противоположное - своп наполняется даже когда памяти еще много свободной. Например: При использовании swap оперативная память не заполняется в первую очередь.

Если много свободной памяти, то в своп ничего и не падает. Своппинг может начинаться при активной работе с файлами, кагда память забита кэшами и встает вопрос что вытеснять - кэши выбрасывать из памяти или неактивную анонимную память вытеснять в своп. Конечно, еще от swappiness зависит - файлы вытеснятся или анонимная память полетит в своп.

Вот еще Крис Даун пишет:

The swapper on kernels before 4.0 has a lot of pitfalls, and has contributed to a lot of people’s negative perceptions about swap due to its overeagerness to swap out pages. On kernels >4.0, the situation is significantly better.

https://chrisdown.name/2018/01/02/in-defence-of-swap.html

– в старых ядрах своппинг был более агрессивным.

Тут чаще жалуются на противоположное - своп наполняется даже когда памяти еще много свободной. Например: При использовании swap оперативная память не заполняется в первую очередь.

Я не понимаю этих жалоб. У меня вот конкретная жалоба - я выделил 20 ГБ диска на своп, а эти 20 ГБ никак не используются. Я деньги за оборудование заплатил, а оно простаивает.

The swapper on kernels before 4.0 has a lot of pitfalls, and has contributed to a lot of people’s negative perceptions about swap due to its overeagerness to swap out pages. On kernels >4.0, the situation is significantly better.

По-мне сделали хуже. Ну да ладно, вопрос не столь существенный.

не более 2.5 от объёма ОЗУ

Тебя жестоко обманули. У меня крутилась ГФШ ПВ на «сервере» с 16Г ОЗУ и 96Г свопа.

Вы это проверяли?

Я взял сейчас 120 Гб ssd, сделал его весь swap'ом, состряпал на Си код, который выделяет 24 Гб, забивает его данными и спит. Потом другим запуском этого кода заполнил/освободил 8 Гб и получил такое:

# free
             total        used        free      shared  buff/cache   available
Mem:        8161496      179396     7953924           0       28176     7828688
Swap:     125034836    25175808    99859028

Потом запустил X, хром, чтобы написать этот пост на ЛОР, youtube, чтобы проверить производительность, никаких проблем нет swap'е лежит 24+ Гб данных, но к ним обращения нет и УМВР.

Конечно, не всё гладко, когда я запустил свой код в X'ах, то всё зависло после выделения 6 Гбайт. Но, ИМХО, это что во взаимодействии X'ов и системы, а не из-за свопа...

Ядро 4.19.

Если у тебя при этом задач на 70 GB RAM и в tmpfs что-то активно пишет, то жестокими фризами и регулярной преждевременной кончиной процессов. Если у тебя там тетрис, пасьянс или десктоп без хрома, то все норм, конечно.

Собственно что мешает переписать swap

то что swap на современном железе не нужен, скоро компьютеры вообще без блочных устройств будут - только энергонезависимая RAM

скоро

не скоро

индексы хранились не в ОЗУ, а так же бы выносились на диск

А где на диске ядро должно искать выгруженный индекс? Держать в памяти индекс выгруженных кусков индекса?

Давай поставим вопрос по другому. Собственно что мешает лично тебе переписать swap так, как тебе надо? Код открыт, никаких ограниченний кроме твоего интеллекта нет. Или хочешь чужими руками жар загребать?

не скоро

блочные устройства это уже легаси, они останутся в виде рамдисков и физические устройства ещё долго будут в ходу - надо же капиталистам бабло из отходов делать.

Если программа обрабатывает такие объёмы данных что они радикально больше ОЗУ, то она должна организовывать свой файл подкачки оптимальным для себя образом. Иначе это плохая программа.

Ваш КО.

скоро компьютеры вообще без блочных устройств будут потому что все диски скупят майнеры

Держать в памяти индекс выгруженных кусков индекса?

Видимо так, в конце концов индекс всё равно будет древообразным, а значит редко используемые концы веток и частично сами веки можно выгружать на диск.

есть тюнинг разных параметров «своппинга» в sysctl.conf