Re: [PATCH 2/2] mm/vmscan: don't demote if there is not enough free memory in the lower memory tier

[Akinobu Mita <akinobu.mita@gmail.com>]

2025年12月17日(水) 21:55 Vlastimil Babka <vbabka@suse.cz>:
>
> On 12/8/25 10:40, Akinobu Mita wrote:
> > On systems with multiple memory-tiers consisting of DRAM and CXL memory,
> > the OOM killer is not invoked properly.
> >
> > Here's the command to reproduce:
> >
> > $ sudo swapoff -a
> > $ stress-ng --oomable -v --memrate 20 --memrate-bytes 10G \
> >     --memrate-rd-mbs 1 --memrate-wr-mbs 1
> >
> > The memory usage is the number of workers specified with the --memrate
> > option multiplied by the buffer size specified with the --memrate-bytes
> > option, so please adjust it so that it exceeds the total size of the
> > installed DRAM and CXL memory.
> >
> > If swap is disabled, you can usually expect the OOM killer to terminate
> > the stress-ng process when memory usage approaches the installed memory
> > size.
> >
> > However, if multiple memory-tiers exist (multiple
> > /sys/devices/virtual/memory_tiering/memory_tier<N> directories exist),
> > and /sys/kernel/mm/numa/demotion_enabled is true and
> > /sys/kernel/mm/lru_gen/min_ttl_ms is 0, the OOM killer will not be invoked
>
> Does this mean only mglru has the problem, or !mglru too?

!mglru has the problem, too.

> Also is min_ttl_ms = 0 a sensible setting? What happens without it?

Setting min_tto_ms = 1 or a longer value will cause kswapd
to trigger the oom-killer.

However, when the stress-ng devshm test was run in addition to
the above test to increase the load, the system remained inoperable
with only the oom-killer by kswapd.

> If !mglru doesn't have this problem, how does the fix affect it?

With this patch, the oom-killer will be triggered directly from
memory allocations, regardless of mglru or not.