Thank you for your message Frederic, I am very much aware of that issue. It’s actually incorrect to say that is a bug: that is how cgroupsv1, which is bundled with rhel8, works. However, it is very counter intuitive. For that reason redhat created the force_cgroup_v2_swappiness parameter uniquely theirselves, it’s not a common Linux parameter.
The specific issue I see in certain cases leading to unreasonable swap usage is Linux workingset detection kicking in, which can choose anonymous memory despite having lots of file memory available, leading to swapping, which sometimes leads to a thrashing situation. It is funny to see how emotional people react to removing swap, and how people go through great efforts to carefully trying wrap that in a technical reason or point to people having said something that agrees with their emotion. I should say that I understand the reluctance, it’s not weird to feel anxious. The kernel has no inherent swap requirement. Of course, removing swap cannot be blindly applied, you have to carefully make it suit your environment, usage and intention. And there ARE cases where swap makes sense (if you have memory usage that exceeds physical memory, and you add enough swap to sustain that). But a database in general typically responds bad to swapping (or anything that fluctuates latency), and when swap removal is sensibly done, it prevents anonymous (including lesser frequently used ;-)) memory from getting swapped. I will not convince everybody, but I hope I can make some people that understand the technology thinking about it and consider the arguments. Friendly regards, Frits > > Op 18 aug 2025 om 18:17 heeft Frédéric Yhuel <frederic.yh...@dalibo.com> het > volgende geschreven: > > > >> On 8/8/25 10:21, Frits Hoogland wrote: >> If swappiness is set to 0, but swap is available, some documentation >> suggests it will never use anonymous memory, however I found this not to be >> true, linux might still choose anonymous memory to reclaim. > > > A bug in RHEL8 meant that swappiness was not taken into account unless > cgroupv2 was configured or vm.force_cgroup_v2_swappiness was set to 1. See > references [1] and [2]. Could this be the cause of your observation? > > [1] https://access.redhat.com/solutions/6785021 > [2] https://github.com/systemd/systemd/issues/9276
