https://bugs.kde.org/show_bug.cgi?id=404057
--- Comment #47 from tagwer...@innerjoin.org --- (In reply to Kai Krakow from comment #46) > ... Just my 2 cents, no need to re-open ... Thank you! My experience is empirical, I tested out various combinations to see how they behaved. Means, of course, that I might have noted the behaviour at one moment in the implementation of the systemd limits / OOM behaviours. I'm pretty sure that behaviours were changing in the period I was testing... That said, I've not noticed the percentages behaving differently than a defined amount of memory (so, I think a "MemoryHigh=25%" on a 2GB system acts the same as a "MemoryHigh=512M"). It would be interesting if this was not the case... I'm pretty sure the "MemoryHigh" is a soft limit, I was able to push the usage to just a little above the given limit but the process slowed down (markedly, when I pushed hard), I think when trying to claim more memory. I tried the same with MemoryMax but this seemed to be a hard limit. I tried setting a MemoryHigh with a slightly higher MemoryMax but it didn't seem to bring any benefits, the MemoryHigh on its own seemed to be quite effective at limiting Baloo's memory use. I'm also pretty sure that even with a defined MemoryHigh, Baloo releases memory when other processes require it. Certainly, there was dropping and rereading of clean pages when Baloo was closing on the limit. That was visible in iotop. I noticed in "pathological cases", indexing large quantities of data and having to manage very many dirty pages, pushed Baloo to swap and performance very clearly suffered (even when the rest of the system has sufficient space). I think it's (likely) worthwhile adding the MemorySwapMax=0 for Baloo to stop it reaching that point (although only if MemoryHigh is reasonable). The argument being an OOM for Baloo is (likely) better than it swapping. This is a value judgement through... I think we should stay with the systemd caps on memory use, there were so many bugs/reports about Baloo slugging performance before the change. Those calls have dropped to a very few (and are more about the limits probably being too low) As I said, this is very much the result of "from the outside in", empirical testing. Not something I can argue is right, particularly given your information (thank you once again), just something I've seen. -- You are receiving this mail because: You are watching all bug changes.
