On Thu, Mar 12, 2020 at 12:48:22PM +0000, Ivan Teterevkov wrote: > On Wed, 11 Mar 2020, David Rientjes wrote: > > On Wed, 11 Mar 2020, Ivan Teterevkov wrote: > > > This patch adds a couple of knobs: > > > > > > - The configuration option (CONFIG_VM_SWAPPINESS). > > > - The command line parameter (vm_swappiness). > > > > > > The default value is preserved, but now defined by CONFIG_VM_SWAPPINESS. > > > > > > Historically, the default swappiness is set to the well-known value 60, > > > and this works well for the majority of cases. The vm_swappiness is also > > > exposed as the kernel parameter that can be changed at runtime too, e.g. > > > with sysctl. > > > > > > This approach might not suit well some configurations, e.g. systemd-based > > > distros, where systemd is put in charge of the cgroup controllers, > > > including the memory one. In such cases, the default swappiness 60 > > > is copied across the cgroup subtrees early at startup, when systemd > > > is arranging the slices for its services, before the sysctl.conf > > > or tmpfiles.d/*.conf changes are applied. > > > > Seems like something that can be fully handled by an initscript that would > > set the sysctl and then iterate the memcg hierarchy propagating the > > non-default value. I don't think that's too much of an ask if userspace > > wants to manipulate the swappiness value. > > > > This is exactly what I'm trying to avoid: in some distros there is no way > to tackle the configuration early enough, e.g. in systemd-based systems > the systemd is the process that starts first and arranges memcg in a way > it's configured, but unfortunately, it doesn't offer the swappiness knob. This sounds like a systemd problem. Have you talked to the systemd people about fixing it in systemd?
