[systemd-devel] systemd-journald may crash during memory pressure

[Kai Krakow]

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.