https://bugs.kde.org/show_bug.cgi?id=404057
--- Comment #46 from Kai Krakow <k...@kaishome.de> --- (In reply to tagwerk19 from comment #45) > Yes, there's been a handful of bug reports where I've "blamed" the 512M > limit. > > I tentatively recommend "MemoryHigh=25%". I don't suppose many people run on > systems with 2G RAM (even as VM's) and having a percentage means Baloo gets > a lot more room to breath on systems with 8G. > > I think "MemoryHigh=40%" is still quite reasonable and I would also include > a "MemorySwapMax=0" to forestall swapping (which does seem to cause problems) MemorySwapMax can lead to OOM situations, even for other processes, if the only swap victim would be baloo. It is fine to swap out some dead pages which the process never uses. And we should be careful with percentages: `MemoryHigh` sets a priority at which the kernel memory manager chooses processes to reduce memory usage (by discard caches, flushing writeback, or swapping anonymous memory). We actually want this to happen, we should be careful to not make baloo the last resort by accidentally giving it the highest memory priority. If we want to limit it, `MemoryMax` should be set (then baloo will never get more memory). But `MemoryHigh` should be set to a reasonable minimum we want to protect for the process so it can make forward progress. Setting it too high creates an inverse effect for other important processes of the desktop. It the lower bound of what is considered high memory usage before making memory available to other processes. Memory is taken away from processes with the highest `MemoryHigh` last. As an idea, baloo could watch `/proc/pressure/memory` and if latencies go high, it could pause for a while and flush its own caches. One cannot try to emulate such a behavior with `MemoryHigh`. Maybe the memory limits should be removed completely, and rather let the kernel do the job using mgLRU (which could be recommended for distributions if it works fine), and then let baloo watch memory pressure instead to throttle itself. The problem is not with baloo reading files and using CPU, it's already highly optimized here. The problem is with how the database uses memmap, so it's directly competing with important desktop processes needing resident memory (it's not designed to compete with other processes for memory). Using memory pressure, we could mark selected memory ranges as "not needed" and flush unwritten data early so it becomes available. I had no more problems with baloo until it added the `MemoryHigh=512M` parameter, so I added another one to force 2G instead. Which makes me wonder if we need that parameter at all. Just my 2 cents, no need to re-open. -- You are receiving this mail because: You are watching all bug changes.
