История изменений
Исправление hakavlad, (текущая версия) :
С трудом верится, что такое примитивное действие (мягкая защита фиксированного количества случайного файлового кеша), реализованное несколькими строчками, так хорошо работает.
Вот и мейнтейнеры ядра не верят и не понимают. Например, Michal Hocko:
I am afraid there is nothing like that available and I would even argue
it doesn't make much sense either.
– https://lore.kernel.org/lkml/20190808163228.GE18351@dhcp22.suse.cz/ - хотя ndrw ровно это и предлагал:
Would it be possible to reserve a fixed (configurable) amount of RAM for caches, and trigger OOM killer earlier, before most UI code is evicted from memory? In my use case, I am happy sacrificing e.g. 0.5GB and kill runaway tasks _before_ the system freezes. Potentially OOM killer would also work better in such conditions.
– и был совершенно прав! - https://lore.kernel.org/lkml/806F5696-A8D6-481D-A82F-49DEC1F2B035@redhazel.co.uk/
Исходная версия hakavlad, :
С трудом верится, что такое примитивное действие (мягкая защита фиксированного количества случайного файлового кеша), реализованное несколькими строчками, так хорошо работает.
Вот и мейнтейнеры ядра не верят и не понимают. Например, Michal Hocko:
I am afraid there is nothing like that available and I would even argue
it doesn't make much sense either.
– https://lore.kernel.org/lkml/20190808163228.GE18351@dhcp22.suse.cz/ - хотя ndrw ровно это и предлагал:
Would it be possible to reserve a fixed (configurable) amount of RAM for caches, and trigger OOM killer earlier, before most UI code is evicted from memory? In my use case, I am happy sacrificing e.g. 0.5GB and kill runaway tasks _before_ the system freezes. Potentially OOM killer would also work better in such conditions. I almost never work at close to full memory capacity, it's always a single task that goes wrong and brings the system down.
– и был совершенно прав! - https://lore.kernel.org/lkml/806F5696-A8D6-481D-A82F-49DEC1F2B035@redhazel.co.uk/