Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception

On Wed, 2008-08-27 at 23:23 -0700, david@lang.hm wrote:
> there are periodic flamefests on the kernel mailing list over the OOM
> killer, if you can propose a better algorithm for it to use than the
> current one that doesn't end up being just as bad for some other workload
> the kernel policy can be changed.
>

Tried that: http://lkml.org/lkml/2007/2/9/275

All they have to do is *not* count shared memory against the process (or
at least not count it against the parent of the process), and the system
may approximate sanity.

> IIRC the reason why it targets the parent process is to deal with a
> fork-bomb type of failure where a program doesn't use much memory itself,
> but forks off memory hogs as quickly as it can. if the OOM killer only
> kills the children the problem never gets solved.

But killing a process won't free shared memory. And there is already a
system-wide limit on shared memory. So what's the point of such a bad
design?

Regards,
    Jeff Davis