On Wed, Sep 25, 2013 at 8:00 AM, Greg Stark <stark@mit.edu> wrote:
>
> On Wed, Sep 25, 2013 at 12:15 AM, Daniel Farina <daniel@heroku.com> wrote:
>>
>> Enable the memcg OOM killer only for user faults, where it's really the
>> only option available.
>
>
> Is this really a big deal? I would expect most faults to be user faults.
>
> It's certainly a big deal that we need to ensure we can handle ENOMEM from
> syscalls and library functions we weren't expecting to return it. But I
> don't expect it to actually reduce the OOM killing sprees by much.
Hmm, I see what you mean. I have been reading through the mechanism:
I got too excited about 'allocations by system calls', because I
thought that might mean brk and friends, except that's not much of an
allocation at all, just reservation. I think.
There is some interesting stuff coming in along with these patches in
bringing the user-space memcg OOM handlers up to snuff that may make
it profitable to issue SIGTERM to backends when a safety margin is
crossed (too bad the error messages will be confusing in that case).
I was rather hoping that a regular ENOMEM could be injected by this
mechanism the next time a syscall is touched (unknown), but I'm not
confident if this is made easier or not, one way or another. One
could imagine the kernel injecting such a fault when the amount of
memory being consumed starts to look hairy, but I surmise part of the
impetus for userspace handling of that is to avoid getting into that
particular heuristics game.
Anyway, I did do some extensive study of cgroups and memcg's
implementation in particular and found it not really practical for
Postgres use unless one was happy with lots and lots of database
restarts, and this work still gives me some hope to try again, even if
smaller modifications still seem necessary.
