On Thu, 2019-08-29 at 09:09 -0700, Edward Chron wrote: > > Feel like you are going in circles to "sell" without any new information. If > > you > > need to deal with OOM that often, it might also worth working with FB on > > oomd. > > > > https://github.com/facebookincubator/oomd > > > > It is well-known that kernel OOM could be slow and painful to deal with, so > > I > > don't buy-in the argument that kernel OOM recover is better/faster than a > > kdump > > reboot. > > > > It is not unusual that when the system is triggering a kernel OOM, it is > > almost > > trashed/dead. Although developers are working hard to improve the recovery > > after > > OOM, there are still many error-paths that are not going to survive which > > would > > leak memories, introduce undefined behaviors, corrupt memory etc. > > But as you have pointed out many people are happy with current OOM processing > which is the report and recovery so for those people a kdump reboot is > overkill. > Making the OOM report at least optionally a bit more informative has value. > Also > making sure it doesn't produce excessive output is desirable. > > I do agree for developers having to have all the system state a kdump > provides that > and as long as you can reproduce the OOM event that works well. But > that is not the > common case as has already been discussed. > > Also, OOM events that are due to kernel bugs could leak memory and over time > and cause a crash, true. But that is not what we typically see. In > fact we've had > customers come back and report issues on systems that have been in continuous > operation for years. No point in crashing their system. Linux if > properly maintained > is thankfully quite stable. But OOMs do happen and root causing them to > prevent > future occurrences is desired. This is not what I meant. After an OOM event happens, many kernel memory allocations could fail. Since very few people are testing those error-paths due to allocation failures, it is considered one of those most buggy areas in the kernel. Developers have mostly been focus on making sure the kernel OOM should not happen in the first place. I still think the time is better spending on improving things like eBPF, oomd and kdump etc to solve your problem, but leave the kernel OOM report code alone.
