22 ms·

Does this result in programs more frequently erroring/crashing because they can't allocate? I don't know how well many of the programs I frequently use on my d

Does this result in programs more frequently erroring/crashing because they can't allocate? I don't know how well many of the programs I frequently use on my desktop (Firefox, GNOME desktop, JVM + IntelliJ, Slack, etc.) handle allocation failures. I'm not sure they would do much better than crash, but I know the default OOM killer settings work well for me. About once a year a real runaway process (usually a throwaway program I'm working on) gets OOM-killed, and that's fine with me.

szmarczak 3mo ago
> Does this result in programs more frequently erroring/crashing because they can't allocate? I run Firefox, VSCodium with LSP, Discord, Signal and there's still space left for a game like CS2. I'm not a heavy user by any means. > I'm not sure they would do much better than crash I have yet to see a program that silently handles allocation failures and doesn't crash. These days everything is coded to crash if no memory :( > About once a year a real runaway process (usually a throwaway program I'm working on) gets OOM-killed In my case it killed system critical processes with no way to recover. With disabled overcommit, it freezes for a while (usually for a minute or two), I close some random program of my choosing and then see in Resource Monitor what's eating my ram.
- __s 3mo ago
  > I have yet to see a program that silently handles allocation failures and doesn't crash Postgres handles allocation failures
fpoling 3mo ago
Java allowed to handle out-of-memory rather well if one wanted to even 25 years ago. Basically one allocated a buffer on a startup taking 5% of memory that the application was supposed to use and made all threads to catch the oom exception. When handling that the buffer would be released, GC would be forced and a special flag would be set asking app to cancel any memory-intensive tasks until enough memory would be released and the buffer can be allocated again. It worked extremely well.
- zbentley 3mo ago
  Yeah, crash ballast is an extremely underrated tool. It also works for the OOM killer: run a daemon with a child process that holds some fixed amount of memory. Adjust OOM scores of everything else on the system lower than the child. If the parent’s waitpid() returns due to an OOM kill, send an alert/shutdown nonessentials/sync buffers to disk and so on.
  - man8alexd 3mo ago
    Maybe you should skip running a useless child process and just use PSI to monitor memory pressure.
    - zbentley 3mo ago
      PSI polling is also good, but there’s no substitute for knowing for sure that the OOM killer is awake and hunting.
      - man8alexd 3mo ago
        You can't know when the OOM killer is awake and hunting. The kernel doesn't know that.
        zbentley 3mo ago
        The approach I originally described provides a useful early warning system for that condition. It’s not perfect, but has proven useful and better than nothing many times.

szmarczak 3mo ago

> Does this result in programs more frequently erroring/crashing because they can't allocate? I run Firefox, VSCodium with LSP, Discord, Signal and there's still space left for a game like CS2. I'm not a heavy user by any means. > I'm not sure they would do much better than crash I have yet to see a program that silently handles allocation failures and doesn't crash. These days everything is coded to crash if no memory :( > About once a year a real runaway process (usually a throwaway program I'm working on) gets OOM-killed In my case it killed system critical processes with no way to recover. With disabled overcommit, it freezes for a while (usually for a minute or two), I close some random program of my choosing and then see in Resource Monitor what's eating my ram.

__s 3mo ago
> I have yet to see a program that silently handles allocation failures and doesn't crash Postgres handles allocation failures

fpoling 3mo ago

Java allowed to handle out-of-memory rather well if one wanted to even 25 years ago. Basically one allocated a buffer on a startup taking 5% of memory that the application was supposed to use and made all threads to catch the oom exception. When handling that the buffer would be released, GC would be forced and a special flag would be set asking app to cancel any memory-intensive tasks until enough memory would be released and the buffer can be allocated again. It worked extremely well.

zbentley 3mo ago
Yeah, crash ballast is an extremely underrated tool. It also works for the OOM killer: run a daemon with a child process that holds some fixed amount of memory. Adjust OOM scores of everything else on the system lower than the child. If the parent’s waitpid() returns due to an OOM kill, send an alert/shutdown nonessentials/sync buffers to disk and so on.
- man8alexd 3mo ago
  Maybe you should skip running a useless child process and just use PSI to monitor memory pressure.
  - zbentley 3mo ago
    PSI polling is also good, but there’s no substitute for knowing for sure that the OOM killer is awake and hunting.
    - man8alexd 3mo ago
      You can't know when the OOM killer is awake and hunting. The kernel doesn't know that.
      - zbentley 3mo ago
        The approach I originally described provides a useful early warning system for that condition. It’s not perfect, but has proven useful and better than nothing many times.