Some interesting news about Linux 3.12 OOM - Mailing list pgsql-hackers

From Daniel Farina
Subject Some interesting news about Linux 3.12 OOM
Date
Msg-id CAAZKuFYMh_n4BL08rBnghex=7Lt29xk2dF98rXeX0WBWep5pug@mail.gmail.com
Whole thread Raw
Responses Re: Some interesting news about Linux 3.12 OOM
List pgsql-hackers
I'm not sure how many of you have been tracking this but courtesy of
lwn.net I have learned that it seems that the OOM killer behavior in
Linux 3.12 will be significantly different.  And by description, it
sounds like an improvement.  I thought some people reading -hackers
might be interested.

Based on the description at lwn, excerpted below, it sounds like the
news might be that systems with overcommit on might return OOM when a
non-outlandish request for memory is made from the kernel.

"""
Johannes Weiner has posted a set of patches aimed at improving this
situation. Following a bunch of cleanup work, these patches make two
fundamental changes to how OOM conditions are handled in the kernel.
The first of those is perhaps the most visible: it causes the kernel
to avoid calling the OOM killer altogether for most memory allocation
failures. In particular, if the allocation is being made in response
to a system call, the kernel will just cause the system call to fail
with an ENOMEMerror rather than trying to find a process to kill. That
may cause system call failures to happen more often and in different
contexts than they used to. But, naturally, that will not be a problem
since all user-space code diligently checks the return status of every
system call and responds with well-tested error-handling code when
things go wrong.
"""

Subject to experiment, this may be some good news, as many programs,
libraries, and runtime environments that may run parallel to Postgres
on a machine are pretty lackadaisical about limiting the amount of
virtual memory charged to them, and overcommit off is somewhat
punishing in those situations if one really needed a large hash table
from Postgres or whatever.  I've seen some cases here where a good
amount of VM has been reserved and caused apparent memory pressure
that cut throughput short of what should ought to be possible.



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Freezing without write I/O
Next
From: Sawada Masahiko
Date:
Subject: Re: Patch for fail-back without fresh backup