On 8 August 2019 12:48:26 BST, Michal Hocko <mho...@kernel.org> wrote:
>>
>> Per default, the OOM killer will engage after 15 seconds of at least
>> 80% memory pressure. These values are tunable via sysctls
>> vm.thrashing_oom_period and vm.thrashing_oom_level.
>
>As I've said earlier I would be somehow more comfortable with a kernel
>command line/module parameter based tuning because it is less of a
>stable API and potential future stall detector might be completely
>independent on PSI and the current metric exported. But I can live with
>that because a period and level sounds quite generic.
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.
The problem with PSI sensing is that it works after the fact (after the freeze
has already occurred). It is not very different from issuing SysRq-f manually
on a frozen system, although it would still be a handy feature for batched
tasks and remote access.
Best regards,
ndrw
