On Thu 08-08-19 16:10:07, ndrw.xf@xxxxxxxxxxxxxx wrote: > > > On 8 August 2019 12:48:26 BST, Michal Hocko <mhocko@xxxxxxxxxx> 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, I am afraid there is nothing like that available and I would even argue it doesn't make much sense either. What would you consider to be a cache? A kernel/userspace reclaimable memory? What about any other in kernel memory users? How would you setup such a limit and make it reasonably maintainable over different kernel releases when the memory footprint changes over time? Besides that how does that differ from the existing reclaim mechanism? Once your cache hits the limit, there would have to be some sort of the reclaim to happen and then we are back to square one when the reclaim is making progress but you are effectively treshing over the hot working set (e.g. code pages) > and trigger OOM killer earlier, before most UI code is evicted from memory? How does the kernel knows that important memory is evicted? E.g. say that your graphic stack is under pressure and it has to drop internal caches. No outstanding processes will be swapped out yet your UI will be completely frozen like. > 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. If you know which task is that then you can put it into a memory cgroup with a stricter memory limit and have it killed before the overal system starts suffering. > 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. Not really. PSI is giving you a matric that tells you how much time you spend on the memory reclaim. So you can start watching the system from lower utilization already. -- Michal Hocko SUSE Labs
