Am Sat, 10 Feb 2018 09:39:35 -0800 schrieb vcaputo: >> After some more research, I found that vm.watermark_scale_factor may be >> the knob I am looking for. I'm going to watch behavior now with a >> higher factor (default = 10, now 200). >> >> > Have you reporteed this to the kernel maintainers? LKML?
No, not yet. I think they are aware of the issues as there's still on- going work to memory allocations within kernel threads, and there's perceivable improvement with every new kernel version. Especially, btrfs has seen a few patches in this area. > While this is interesting to read on systemd-devel, it's not right > venue. What you describe sounds like a regression that probably should > be improved upon. I know it's mostly off-topic. But the problem is most visible in systemd- journald and I think there are some users here which may have a better understanding of the underlying problem, or maybe even found solutions to it. One approach for me was using systemd specific slices. So it may be interesting to other people. > Also, out of curiosity, are you running dmcrypt in this scenario? If > so, is swap on dmcrypt as well? No, actually not. I'm using bcache for rootfs which may have similar implications to memory allocations. Swap is just plain swap distributed across 4 disks. If I understand correctly, dmcrypt may expose this problem further because it needs to "double buffer" memory while passing it further down the storage layer. I had zswap enabled previously which may expose this problem, too. I now disabled it and later enabled THP again. THP now runs very well again. Looks like zswap and THP don't play well together. OTOH, these options were switched on and off during different kernel versions. So it may also be an effect of fixes in newer kernels. -- Regards, Kai Replies to list-only preferred. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel