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 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? -- Michal Hocko SUSE Labs
