On Mon, May 16, 2022 at 11:56 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > On Mon 16-05-22 15:29:42, Yosry Ahmed wrote: > > The discussions on the patch series [1] to add memory.reclaim has > > shown that it is desirable to add an argument to control the type of > > memory being reclaimed by invoked proactive reclaim using > > memory.reclaim. > > > > I am proposing adding a swappiness optional argument to the interface. > > If set, it overwrites vm.swappiness and per-memcg swappiness. This > > provides a way to enforce user policy on a stateless per-reclaim > > basis. We can make policy decisions to perform reclaim differently for > > tasks of different app classes based on their individual QoS needs. It > > also helps for use cases when particularly page cache is high and we > > want to mainly hit that without swapping out. > > Can you be more specific about the usecase please? Also how do you For example for a class of applications it may be known that reclaiming one type of pages anon/file is more profitable or will incur an overhead, based on userspace knowledge of the nature of the app. If most of what an app use for example is anon/tmpfs then it might be better to explicitly ask the kernel to reclaim anon, and to avoid reclaiming file pages in order not to hurt the file cache performance. It could also be a less aggressive alternative to /proc/sys/vm/drop_caches. > define the semantic? Behavior like vm_swappiness is rather vague because > the kernel is free to ignore (and it does indeed) this knob in many > situations. What is the expected behavior when user explicitly requests > a certain swappiness? My initial thoughts was to have the same behavior as vm_swappiness, but stateless. If a user provides a swappiness value then we use it instead of vm_swappiness. However, I am aware that the definition is vague and there are no guarantees here, the only reason I proposed swappiness vs. explicit type arguments (like the original RFC and Roman's reply) is flexibility. It looks like explicit type arguments would be more practical though. I will continue the discussion replying to Roman. > -- > Michal Hocko > SUSE Labs
