Using deadline vs. noop as the scheduler on my disk has no effect. I've tuned everything I can think of in /proc/sys/vm, to no effect - swappiness, dirty_writeback, overcommit_ratio, dirty_background_ratio. I've tried 'echo 3 > /proc/sys/vm/drop_caches'; when I cat this file back, it stays at '3' - which seems to imply that it's received the instruction to drop the cache, but is failing to do so?!
The size of the un-freeable cache is dependent on what I have running. If I check from a console immediately after boot (with only the lightdm greeter running), the cache bottoms out at about 200MB in size. If I check after login without starting firefox, it's about 700MB. If I start firefox, it's about 1.4GB. I have no idea what is in those caches, but I cannot for the life of me convince the kernel to give them up for my apps to have more memory. For reference, my system uses LVM and my root filesystem and /home partition are using LUKS. I wonder if the use of LUKS somehow means the kernel is creating a non-freeable cache in front of the encrypted disk. However, if it is, it's *very* buggy, as a check with lsof tells me that the cache is many times the size of *all* the files opened on those disks by *all* the processes on the system (total currently open size: 128MB). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1152736 Title: system swapping itself to death in raring for no good reason To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1152736/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
