4 ms·

Okay, if unused memory is wasted and there are truly no consequences for the "free" column reading zero, then why on a busy system do I get UI chugging and othe

Okay, if unused memory is wasted and there are truly no consequences for the "free" column reading zero, then why on a busy system do I get UI chugging and otherwise poor (bordering on unusable) performance under this condition that is immediately resolved by forcing the caches to drop and freeing multiple gigabytes? Whatever conceivable speedup there is from 12 GB of file cache as opposed to 11 is obliterated multiple times over from the time lost by having to do this dance, or worse, recovering after the oom killer wipes out my X session or browser.

AnotherGoodName 3y ago
>recovering after the oom killer wipes out my X session or browser. Perhaps you can share more details of what you're doing to force the cache to drop and what the side effects are exactly because an OOM can't be caused by the file cache since the total free memory available to applications remains the same. The whole point of the file cache is to use otherwise unallocated memory and give it up the moment it's needed. There should not be an OOM from this short of an OS bug or an over allocated virtualized system.
- Karunamon 3y ago
  echo 3 > /proc/sys/vm/drop_caches Last time I ran into this was a couple of years ago on a stock Arch system. (Disabilities forced me back to Windows). Every time, the largest memory consumer was the web browser. Also every time, the system became nearly unresponsive due to swap thrashing (kswapd at the top of the CPU usage list, most of which was I/O wait). Last time I complained about this problem, someone suggested installing zram which did stop it from happening. However, this does not change the fact that there is some pathological failure case that contradicts the central thesis (not to mention, smug tone) of this website and makes searching for solutions to the problem infuriating.
PhilipRoman 3y ago
I find that task priorities in general are not strict enough under Linux. Try running a cpu heavy but very low priority task in background and it still manages to measurably affect the latency of the more important process. And this is just the CPU, not to mention disk utilization and network usage. I was too lazy to find a proper solution, so I just used mlockall after allocating a massive heap and pin the process to a core that is reserved only for this specific purpose. I think cgroups has very flexible tools for reserving system wide resources, but haven't had the time to test it yet.

AnotherGoodName 3y ago

>recovering after the oom killer wipes out my X session or browser. Perhaps you can share more details of what you're doing to force the cache to drop and what the side effects are exactly because an OOM can't be caused by the file cache since the total free memory available to applications remains the same. The whole point of the file cache is to use otherwise unallocated memory and give it up the moment it's needed. There should not be an OOM from this short of an OS bug or an over allocated virtualized system.

Karunamon 3y ago
echo 3 > /proc/sys/vm/drop_caches Last time I ran into this was a couple of years ago on a stock Arch system. (Disabilities forced me back to Windows). Every time, the largest memory consumer was the web browser. Also every time, the system became nearly unresponsive due to swap thrashing (kswapd at the top of the CPU usage list, most of which was I/O wait). Last time I complained about this problem, someone suggested installing zram which did stop it from happening. However, this does not change the fact that there is some pathological failure case that contradicts the central thesis (not to mention, smug tone) of this website and makes searching for solutions to the problem infuriating.

PhilipRoman 3y ago

I find that task priorities in general are not strict enough under Linux. Try running a cpu heavy but very low priority task in background and it still manages to measurably affect the latency of the more important process. And this is just the CPU, not to mention disk utilization and network usage. I was too lazy to find a proper solution, so I just used mlockall after allocating a massive heap and pin the process to a core that is reserved only for this specific purpose. I think cgroups has very flexible tools for reserving system wide resources, but haven't had the time to test it yet.