Messages in this thread | | | From | Al Boldi <> | Subject | Re: additional oom-killer tuneable worth submitting? | Date | Fri, 8 Dec 2006 19:59:04 +0300 |
| |
Alan wrote: > > What I understood from Arjan is that the problem isn't swapspace, but > > rather that shared-libs are implement via a COW trick, which always > > overcommits, no matter what. > > The zero overcommit layer accounts address space not pages.
So OOM can still occur?
> > Are you saying there is some new no-overcommit functionality in 2.6.19, > > or has this been there before? > > Red Hat Enterprise Linux for a very long time, got merged upstream a long > long time ago to. Then got various fixes along the way. It's old > functionality.
That's what I thought, but it's still really easy to OOM even with no-overcommit.
Using ulimit -v [total VMsize/runqueue] seems to inhibit this rather effectively, but needs to be maintained dynamically per process.
Couldn't this be handled by the kernel?
Thanks!
-- Al
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |