5 ms·

I do, because your program isn't the only thing running on my system. Low free RAM means paging, and generalized slowdowns when something else RAM-hungry, like

I do, because your program isn't the only thing running on my system. Low free RAM means paging, and generalized slowdowns when something else RAM-hungry, like a game or a web browser, is invoked. Memory is a limited resource to be used judiciously, not an all-you-can-eat buffet.

thawkins 5y ago
what's the point of having a bunch of ram sitting around doing nothing, I would rather have a system that had zero free ram but managed its address space well, so that changing ram usage was painless. why pay good money to have hardware sitting idle?.
- Karunamon 5y ago
  The same reason I refill my car's gas tank long before it hits zero; low/no resource problems range from irritating to catastrophic. Unused RAM isn't wasted, it's headroom.
  - kaba0 5y ago
    But you OS doesn’t have to find a petrol station it may not even be able to reach — it can just swap to SSD or the best - swap to RAM itself by compressing pages (zram on linux and mac does it as well). Empty RAM is seriously wasted unless it is some embedded system where you are managing memory and need some strange latency requirements.
    - Karunamon 5y ago
      As described below, that's what's supposed to happen, but the default kernel configuration in mainstream distros will happily hold onto caches while swapping so hard to be unusable, or worse, loosing the OOM killer to wreak havoc on my workspace. This is unacceptable, and this is why I want headroom. At the end of the day, if my system wildly misbehaves under high memory pressure, and forcing the pressure down resolves the misbehavior (or keeping a certain amount of headroom prevents it from happening outright), "linux ate my ram" is an accurate description of what happened and no amount of tut-tutting telling me that it doesn't work the way I just got done seeing it work changes that. I'll give zram a try, but the problem here is poor usage of memory (both in priority and badly-behaved bloatware), not quantity of memory available. I'm not a kernel developer, I shouldn't have to dork around with these kinds of knobs to get sane behavior.
staticassertion 5y ago
Unless you're seeing other processes crash because of a lack of RAM this isn't an issue, your OS will page things in/ out, including in Chrome, based on memory pressure.
- Karunamon 5y ago
  Yes it is an issue. Under high memory pressure, we start digging into swap, and at that point, the UI is starting to significantly chug. Worse, this often happens when there's plenty of cache to evict. I can and have restored a nigh-unusable desktop to normal operation many times with a painfully entered `echo 3 > /proc/sys/vm/drop_caches` from a new TTY, instantly resolving the pressure and giving me time to find and terminate the presumptuous program who thinks its entitled to 3/4 of system memory (usually some flavor of web browser or electron bloatware). Why's the kernel so jealously guarding its cache allocation and making the UX suck harder? Not a clue. Whatever performance penalty I take from nuking caches is far, far less than from allowing free memory to fill up and dealing with the pathological behavior surrounding that.
  - staticassertion 5y ago
    > Under high memory pressure Just to again note that just because a program says it's using N MB of RAM doesn't mean that all of that RAM is actually paged in. Every thread you execute has an 8+MB stack but most of it won't get allocated for the majority of programs. > we start digging into swap, and at that point, the UI is starting to significantly chug. Only if you're constantly swapping in and out of swap. Just putting something into swap and never retrieving it won't case issues. I'd generally recommend disabling swap altogether though and just letting OOM take out misbehaving processes. This isn't all to say that using less memory is 'bad', but when people say 'oh that program is such a memory hog' I wonder if they might be measuring incorrectly, or not realizing what it's doing with that memory.
    - Karunamon 5y ago
      >Only if you're constantly swapping in and out of swap. Which, in the experience I just gave, is what's happening. System memory at some high 90s percent utilization, swap usage creeping up, kswapd with a ton of CPU usage, and worst of all, UI chugging. If it wasn't 'actual' memory usage, why does dropping caches, instantly freeing up some amount of memory, restore responsiveness? I've tried operating swapless before, but that just means OOM killer kicks in even when there's cache to evict. That seems like a priority inversion to me - of anything paged in, shouldn't cache have the absolute lowest priority, and be the first thing to go when memory's needed for other things?

thawkins 5y ago

what's the point of having a bunch of ram sitting around doing nothing, I would rather have a system that had zero free ram but managed its address space well, so that changing ram usage was painless. why pay good money to have hardware sitting idle?.

Karunamon 5y ago
The same reason I refill my car's gas tank long before it hits zero; low/no resource problems range from irritating to catastrophic. Unused RAM isn't wasted, it's headroom.
- kaba0 5y ago
  But you OS doesn’t have to find a petrol station it may not even be able to reach — it can just swap to SSD or the best - swap to RAM itself by compressing pages (zram on linux and mac does it as well). Empty RAM is seriously wasted unless it is some embedded system where you are managing memory and need some strange latency requirements.
  - Karunamon 5y ago
    As described below, that's what's supposed to happen, but the default kernel configuration in mainstream distros will happily hold onto caches while swapping so hard to be unusable, or worse, loosing the OOM killer to wreak havoc on my workspace. This is unacceptable, and this is why I want headroom. At the end of the day, if my system wildly misbehaves under high memory pressure, and forcing the pressure down resolves the misbehavior (or keeping a certain amount of headroom prevents it from happening outright), "linux ate my ram" is an accurate description of what happened and no amount of tut-tutting telling me that it doesn't work the way I just got done seeing it work changes that. I'll give zram a try, but the problem here is poor usage of memory (both in priority and badly-behaved bloatware), not quantity of memory available. I'm not a kernel developer, I shouldn't have to dork around with these kinds of knobs to get sane behavior.

staticassertion 5y ago

Unless you're seeing other processes crash because of a lack of RAM this isn't an issue, your OS will page things in/ out, including in Chrome, based on memory pressure.

Karunamon 5y ago
Yes it is an issue. Under high memory pressure, we start digging into swap, and at that point, the UI is starting to significantly chug. Worse, this often happens when there's plenty of cache to evict. I can and have restored a nigh-unusable desktop to normal operation many times with a painfully entered `echo 3 > /proc/sys/vm/drop_caches` from a new TTY, instantly resolving the pressure and giving me time to find and terminate the presumptuous program who thinks its entitled to 3/4 of system memory (usually some flavor of web browser or electron bloatware). Why's the kernel so jealously guarding its cache allocation and making the UX suck harder? Not a clue. Whatever performance penalty I take from nuking caches is far, far less than from allowing free memory to fill up and dealing with the pathological behavior surrounding that.
- staticassertion 5y ago
  > Under high memory pressure Just to again note that just because a program says it's using N MB of RAM doesn't mean that all of that RAM is actually paged in. Every thread you execute has an 8+MB stack but most of it won't get allocated for the majority of programs. > we start digging into swap, and at that point, the UI is starting to significantly chug. Only if you're constantly swapping in and out of swap. Just putting something into swap and never retrieving it won't case issues. I'd generally recommend disabling swap altogether though and just letting OOM take out misbehaving processes. This isn't all to say that using less memory is 'bad', but when people say 'oh that program is such a memory hog' I wonder if they might be measuring incorrectly, or not realizing what it's doing with that memory.
  - Karunamon 5y ago
    >Only if you're constantly swapping in and out of swap. Which, in the experience I just gave, is what's happening. System memory at some high 90s percent utilization, swap usage creeping up, kswapd with a ton of CPU usage, and worst of all, UI chugging. If it wasn't 'actual' memory usage, why does dropping caches, instantly freeing up some amount of memory, restore responsiveness? I've tried operating swapless before, but that just means OOM killer kicks in even when there's cache to evict. That seems like a priority inversion to me - of anything paged in, shouldn't cache have the absolute lowest priority, and be the first thing to go when memory's needed for other things?