https://bugs.kde.org/show_bug.cgi?id=361521
Kai Krakow <k...@kaishome.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |k...@kaishome.de
--- Comment #17 from Kai Krakow <k...@kaishome.de> ---
(In reply to David Edmundson from comment #12)
> Large virtual memory isn't a problem. It can just mean we've mapped a file
> on disk, even a file that isn't actually that size. We're not using up /any/
> resources by doing it.
>
> If your resident memory size is high, that's a problem (and the 450Mb is
> high, that we should identify and fix). Virtual memory being high is pretty
> much a non issue until proved otherwise.
You sound pretty sure about this but I'm seeing the same behavior regarding
baloo_index:
7f41b8000000-7f81b8000000 r--s 268435456 KB 20 KB 10 KB 20 KB
0 KB 0 KB 0 KB 20 KB 0 KB 0 KB 0 KB 0 KB 0 KB 0 KB
0 KB 0 KB /home/kakra/.local/share/baloo/index
That's around 255GB already. Letting it run a few days more it will eventually
reach 2TB, and that is when my system starts to act strange: The kernel oom
killer kicks in, high memory pressure is reported, file system kernel threads
start to freeze, mouse pointer freezes, until I manage to kill plasmashell. I
guess that such huge virtual memory mappings (although they are sparse and use
almost no real memory) eat up all memory mapping tables and the kernel gets
into trouble finding space in the page tables.
I've once seen plasmashell showing a VMM size of 3.8 TB in top while my system
started to feel very sluggish as if memory pressure forces swapping - but it
wasn't swapping and I had a lot of free physical memory.
Having a RSS of half a gig is absolutely no problem for me. I don't see any
point in chasing that down before the huge VMM size problem was fixed.
--
You are receiving this mail because:
You are watching all bug changes.
