On Thu, Nov 30, 2023 at 07:36:53AM -0800, Dan Schatzberg wrote: > (Sorry for the resend - forgot to cc the mailing lists) > > This patch proposes augmenting the memory.reclaim interface with a > swappiness=<val> argument that overrides the swappiness value for that instance > of proactive reclaim. > > Userspace proactive reclaimers use the memory.reclaim interface to trigger > reclaim. The memory.reclaim interface does not allow for any way to effect the > balance of file vs anon during proactive reclaim. The only approach is to adjust > the vm.swappiness setting. However, there are a few reasons we look to control > the balance of file vs anon during proactive reclaim, separately from reactive > reclaim: > > * Swapout should be limited to manage SSD write endurance. In near-OOM Is this about swapout to SSD only? > situations we are fine with lots of swap-out to avoid OOMs. As these are > typically rare events, they have relatively little impact on write endurance. > However, proactive reclaim runs continuously and so its impact on SSD write > endurance is more significant. Therefore it is desireable to control swap-out > for proactive reclaim separately from reactive reclaim This is understandable but swapout to zswap should be fine, right? (Sorry I am not following the discussion on zswap patches from Nhat. Is the answer there?)
