https://bugs.kde.org/show_bug.cgi?id=404057
--- Comment #49 from Kai Krakow <k...@kaishome.de> --- (In reply to tagwerk19 from comment #47) > 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... No, it should not be different. In the end, it boils down to fixed numbers as can be seen in `systemctl --user status kde-baloo.service`: # Memory: 136.4M (high: 2.0G available: 1.8G peak: 1.3G swap: 18.4M swap peak: 18.5M zswap: 6.9M) (where "high" is calculated from percentage to this number) > 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. MemoryHigh is not a limit. MemoryHigh is an indicator/hint for the kernel beyond which value the process group is considered to use a high amount of memory. Now, if the kernel needs memory, it will reclaim memory from process groups first that are most above their "MemoryHigh" value. Thus, if you make this very high, the kernel will decide to reclaim memory from baloo last because it is potentially the only service with a very high "MemoryHigh" value. The service is allowed to go beyond that memory usage just fine as long as the kernel has no need for other memory. This is also a problem in itself if mixing non-memory constrained services with ones that have this setting. The system becomes very unbalanced unless you adjust it for your very own needs. Leaving `MemoryHigh` empty instructs cgroups to balance memory usage in a fair way. > I > tried the same with MemoryMax but this seemed to be a hard limit. Yes, it is a hard limit. Allocations beyond `MemoryMax` will force the process group to swap out inactive memory of itself. > 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. Cannot work. `MemoryHigh` is not a limit, it's a hint for the memory management when to consider a service to use "too much" memory, so services beyond that allocation will be considered for reclaim first. Or viewed from the other side: `MemoryHigh` is a type of resident memory protection which the kernel _tries_ to guarantee to the service (`MemoryMin` will force the guarantee). > I'm also pretty sure that even with a defined MemoryHigh, Baloo releases > memory when other processes require it. Yes, because it's a "soft guarantee", not a "soft limit". If the kernel has no more other processes to reclaim memory from, it will start reclaiming memory from `MemoryHigh` services below their setting, in order of priority that makes sense in that context. Baloo itself surely will free memory, too, by itself, and that's reflected here. Those memory allocations also include cache which baloo cannot directly control. The kernel tracks page cache ownership per cgroup, and accounts that to memory usage, too. I'm pretty sure `MemoryHigh` has been set so low (512M) because someone considered it a soft limit, but it's a soft guarantee. And setting it too low will hint the kernel to reclaim memory from such processes first - and that's usually cache before swapping memory out (depends on vm.swappiness). Thus, `MemoryHigh` should be set to a proper value that includes the active working set of memory pages for the process + a good value for cache to let it do it's job without stuttering the desktop. That settles around 1.5G of memory for me. But OTOH, that means, we will also protect its memory even if baloo is idle (and may be fine with using less than 1.5G RAM including caches). Thus I think, it may be a better idea to completely leave that value empty, maybe only include it as a comment with explanation so users can tune it easily with `systemctl --user edit kde-baloo.service`. > 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... `MemoryHigh` is a two-edged sword... You can stop the observed behavior by using a high value like `50%`. But then, when baloo becomes idle again, it will only slowly give memory back to other parts of the system unless the system is already under memory pressure. IMHO, it's not a knob for services which switch between work and idle a lot. It's meant as a knob for system services which need a defined response time. It's also difficult to tune because its behavior depends a lot of whether the rest of the system is idle or under stress: It's a soft guarantee, not a way of controlling memory. If we want to prevent baloo from thrashing, we should use something like `MemoryLow=512M` which is similar to `MemoryMin` but it's a soft value. It guarantees baloo at least 512M if the system isn't under stress. > 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) I'll try without memory for some weeks, or even with MemoryLow, and may report back. > 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. No problem. I've experimented with `MemoryHigh/Low/Min` a lot, and on desktop it's almost always counter-productive. And in the end, I've found it's rather a problem with btrfs itself disrupting the page cache with memory fragmentation - and systemd memory settings cannot solve that at all. (see observations here: https://github.com/Zygo/bees/issues/260 and linked discussions) For me, baloo usually became a problem when btrfs caused high memory fragmentation, and then yes, stopping baloo made the system respond better again - but that's not because we stopped baloo. The system still has extremely low allocatable memory to work with even if it shows a lot of cache or free memory. The next process that uses some more memory will kick off the same system behavior again a while later. Limiting memory of baloo just reduced the probability of the system to run into these problems early. But as we can see, using `MemoryHigh=512M` can cause more harm than good. What the author of that commit wanted to do is probably more in the sense of `MemoryLow=512M`. The naming of those settings is a little counter-intuitive: we want to prevent baloo to go below 512M of memory so it doesn't run into swap storms or cache thrashing too easily when the system is under memory stress. -- You are receiving this mail because: You are watching all bug changes.
