5 ms·

It honestly isn't. Out of memory means, your system is simply not designed for the task at hand. The kernel returning -ENOMEM only masks the fact that eventual

It honestly isn't. Out of memory means, your system is simply not designed for the task at hand. The kernel returning -ENOMEM only masks the fact that eventually Linux will have to OOM Panic if it can't OOM Kill. Hell imagine the swapping and the I/O spike because your VFS cache has been or is currently being purged. I honestly think the best case is to just fail when a fundamental resource is simply not there.

lxgr 5y ago
> Out of memory means, your system is simply not designed for the task at hand. Speaking as somebody who's never built such a system, wouldn't maintaining some opportunistic cache (e.g. for some space-time-tradeoff) be a valid use case of asking for more memory and gracefully degrading in case it's not available? Error handling would simply consist of not expanding the cache size (if it happens during an allocation related to the cache) or freeing up some cache memory (if it happens for an essential allocation).
- marcosdumay 5y ago
  You can free opportunistic caches, undo some calculations (and optionally put a descriptor of them into the disk), freeze some internal services into disk, not start some large task (and keep the small but time critical ones running)... There are all sorts of things you could do on out of memory errors. But on practice programs ask the users to decide those things, and just fail if the user choice is invalid. It's very rare that some program makes those decisions by itself, and it's usually frowned upon, because each single program can not assume that it owns the entire system.
- prussian 5y ago
  I mean, it sounds like you're describing overcommit to me. Ask whatever large amount you want. Maybe even be like webkit and use overcommit for heap isolation. It works out great for the userspace case, until the limits are actually reached and you still have a failure problem, one probably harder to deal with than without overcommit.
cies 5y ago
Zig (another language fit for low level programming, like C and Rust) begs to differ. [1]: https://ziglang.org/learn/why_zig_rust_d_cpp/#no-hidden-allocations https://ziglang.org/learn/why_zig_rust_d_cpp/#no-hidden-allo...
- littlestymaar 5y ago
  I love how the section about Rust links to a github issue that is more than five years-old, when the fallible allocation story has evolved so much in the past year.
  - cies 5y ago
    So how has it? I was not aware it has changed (also I dont need the changes, as I use Rust for more highlevel stuff)
    - littlestymaar 5y ago
      There are new methods returning a Result instead of panicking, slowly being implemented for all allocating collections in the standard library. see https://github.com/rust-lang/rust/issues/48043 https://github.com/rust-lang/rust/issues/48043 and https://github.com/rust-lang/rust/pull/80310 https://github.com/rust-lang/rust/pull/80310
      - cies 5y ago
        Like what was mentioned in the linked thread, the "try_*" functions. This is what Zig has as default behavior.
- prussian 5y ago
  What does this have to do with my comment? If you're out of memory, how can zig know you can just continue on? What if your memory is held in tasks that are effectively dead-locked because a dependent task is incapable of allocating? There are many things that can be happening once memory is effectively maxed out. The more common towards the edge is higher I/O and the system crawls. I'm sure Zig is great, but I don't see from what you linked how that changes what I said.
deleted 5y ago
[deleted]
dTal 5y ago
Is it really too much to ask, in 2021, that our computers be cabable of saying "I'm sorry Dave, I can't do that", instead of "Halt and Catch Fire"?
magicalhippo 5y ago
> I honestly think the best case is to just fail when a fundamental resource is simply not there. Indeed. I'm using Firefox in a VM. It's a pain, because invariably at some point Firefox uses enough memory that the VM starts to swap. And then the whole thing grinds to a halt, and I usually just end up with the VM equivalent of power-off. Instead I'd be perfectly fine with the kernel telling Firefox "computer says no" when it tries to malloc, before the system runs out of memory, and then Firefox can do whatever it wants with that. Yes I know there's some cgroups magic or whatever I can do, but man, why does it have to be so painful?
- sfink 5y ago
  Firefox is a bit of an interesting case. We have essentially 3 categories of allocations: (1) those that are large and/or the size is user-controlled, which are (mostly) handled; (2) most of those that happen within the JS engine, which are handled but we're constantly debating whether it's worth the cost; and (3) all the rest, which includes all other allocations outside the JS engine as well as the ones within the JS engine that are expected to be rare and are too hard to handle in any sensible way. For (3), we crash on OOM. So if you do use cgroups or ulimit or whatever, Firefox may do something reasonable with OOMs. Or it may not, depending on what code sees the OOM. It's still an open question how often the JS engine handling an OOM is worthwhile (as in, it won't just continue to OOM until it finds something that will choose to crash.) OOM telemetry is a little iffy, so I don't trust statistics based on it. The cost of (2) is not just code size and code complexity. It's also a larger vulnerability surface that is rarely exercised. Within the JS engine, we have ways to synthesize OOM events to at least get some level of testing. (We'll run a chunk of code repeatedly, OOMing on the 1st, 2nd, 3rd, ... allocation, and make sure we either handle it properly or do a controlled crash.)
  - magicalhippo 5y ago
    Personally I'd be fine with crashing a tab or five. For example Slack uses several gigabytes of memory if I forget to reload the tab every hour or so. It has a DOM live-leak or something. Perfectly fine to let that thing crash and burn. Letting my PC grind to a halt is far worse for me. Now my point is, I don't want the kernel to try to fluff Firefox and try to limp it along. Sure for a few applications it's good that the kernel tries its utmost. But in most cases, I don't want one application to dictate my PC's performance. Gone are the days where I use my PC for one thing at a time. And if the kernel was more strict with applications, then hopefully sane OOM handling would force its way into more applications.
patrec 5y ago
> Out of memory means, your system is simply not designed for the task at hand. You seem not very familiar with the memory "management" behavior of Linux and the wonderful ecosystem it has engendered. For example no matter how much physical memory you have, Chrome for example will just crash all the time if you turn off Linux's insane "lie about memory allocation succeeding" default.
- prussian 5y ago
  I'm more than familiar with overcommit and it has nothing to do with being out of memory. In fact, im explicitly talking about the kernel failing to allocate (-ENOMEM) in a alleged future driver. It may interest you to know the WebKit takes this behavior to 11 and actually uses overcommit to isolate heaps even. That "runway" of memory between heaps is not used and thus the +99GiB virtual memory size is bunk. Really nothing to do with being out of memory.

lxgr 5y ago

> Out of memory means, your system is simply not designed for the task at hand. Speaking as somebody who's never built such a system, wouldn't maintaining some opportunistic cache (e.g. for some space-time-tradeoff) be a valid use case of asking for more memory and gracefully degrading in case it's not available? Error handling would simply consist of not expanding the cache size (if it happens during an allocation related to the cache) or freeing up some cache memory (if it happens for an essential allocation).

marcosdumay 5y ago
You can free opportunistic caches, undo some calculations (and optionally put a descriptor of them into the disk), freeze some internal services into disk, not start some large task (and keep the small but time critical ones running)... There are all sorts of things you could do on out of memory errors. But on practice programs ask the users to decide those things, and just fail if the user choice is invalid. It's very rare that some program makes those decisions by itself, and it's usually frowned upon, because each single program can not assume that it owns the entire system.
prussian 5y ago
I mean, it sounds like you're describing overcommit to me. Ask whatever large amount you want. Maybe even be like webkit and use overcommit for heap isolation. It works out great for the userspace case, until the limits are actually reached and you still have a failure problem, one probably harder to deal with than without overcommit.

cies 5y ago

Zig (another language fit for low level programming, like C and Rust) begs to differ. [1]: https://ziglang.org/learn/why_zig_rust_d_cpp/#no-hidden-allocations https://ziglang.org/learn/why_zig_rust_d_cpp/#no-hidden-allo...

littlestymaar 5y ago
I love how the section about Rust links to a github issue that is more than five years-old, when the fallible allocation story has evolved so much in the past year.
- cies 5y ago
  So how has it? I was not aware it has changed (also I dont need the changes, as I use Rust for more highlevel stuff)
  - littlestymaar 5y ago
    There are new methods returning a Result instead of panicking, slowly being implemented for all allocating collections in the standard library. see https://github.com/rust-lang/rust/issues/48043 https://github.com/rust-lang/rust/issues/48043 and https://github.com/rust-lang/rust/pull/80310 https://github.com/rust-lang/rust/pull/80310
    - cies 5y ago
      Like what was mentioned in the linked thread, the "try_*" functions. This is what Zig has as default behavior.
prussian 5y ago
What does this have to do with my comment? If you're out of memory, how can zig know you can just continue on? What if your memory is held in tasks that are effectively dead-locked because a dependent task is incapable of allocating? There are many things that can be happening once memory is effectively maxed out. The more common towards the edge is higher I/O and the system crawls. I'm sure Zig is great, but I don't see from what you linked how that changes what I said.

deleted 5y ago

[deleted]

dTal 5y ago

Is it really too much to ask, in 2021, that our computers be cabable of saying "I'm sorry Dave, I can't do that", instead of "Halt and Catch Fire"?

magicalhippo 5y ago

> I honestly think the best case is to just fail when a fundamental resource is simply not there. Indeed. I'm using Firefox in a VM. It's a pain, because invariably at some point Firefox uses enough memory that the VM starts to swap. And then the whole thing grinds to a halt, and I usually just end up with the VM equivalent of power-off. Instead I'd be perfectly fine with the kernel telling Firefox "computer says no" when it tries to malloc, before the system runs out of memory, and then Firefox can do whatever it wants with that. Yes I know there's some cgroups magic or whatever I can do, but man, why does it have to be so painful?

sfink 5y ago
Firefox is a bit of an interesting case. We have essentially 3 categories of allocations: (1) those that are large and/or the size is user-controlled, which are (mostly) handled; (2) most of those that happen within the JS engine, which are handled but we're constantly debating whether it's worth the cost; and (3) all the rest, which includes all other allocations outside the JS engine as well as the ones within the JS engine that are expected to be rare and are too hard to handle in any sensible way. For (3), we crash on OOM. So if you do use cgroups or ulimit or whatever, Firefox may do something reasonable with OOMs. Or it may not, depending on what code sees the OOM. It's still an open question how often the JS engine handling an OOM is worthwhile (as in, it won't just continue to OOM until it finds something that will choose to crash.) OOM telemetry is a little iffy, so I don't trust statistics based on it. The cost of (2) is not just code size and code complexity. It's also a larger vulnerability surface that is rarely exercised. Within the JS engine, we have ways to synthesize OOM events to at least get some level of testing. (We'll run a chunk of code repeatedly, OOMing on the 1st, 2nd, 3rd, ... allocation, and make sure we either handle it properly or do a controlled crash.)
- magicalhippo 5y ago
  Personally I'd be fine with crashing a tab or five. For example Slack uses several gigabytes of memory if I forget to reload the tab every hour or so. It has a DOM live-leak or something. Perfectly fine to let that thing crash and burn. Letting my PC grind to a halt is far worse for me. Now my point is, I don't want the kernel to try to fluff Firefox and try to limp it along. Sure for a few applications it's good that the kernel tries its utmost. But in most cases, I don't want one application to dictate my PC's performance. Gone are the days where I use my PC for one thing at a time. And if the kernel was more strict with applications, then hopefully sane OOM handling would force its way into more applications.

patrec 5y ago

> Out of memory means, your system is simply not designed for the task at hand. You seem not very familiar with the memory "management" behavior of Linux and the wonderful ecosystem it has engendered. For example no matter how much physical memory you have, Chrome for example will just crash all the time if you turn off Linux's insane "lie about memory allocation succeeding" default.

prussian 5y ago
I'm more than familiar with overcommit and it has nothing to do with being out of memory. In fact, im explicitly talking about the kernel failing to allocate (-ENOMEM) in a alleged future driver. It may interest you to know the WebKit takes this behavior to 11 and actually uses overcommit to isolate heaps even. That "runway" of memory between heaps is not used and thus the +99GiB virtual memory size is bunk. Really nothing to do with being out of memory.