Willy Tarreau wrote:
> On Sat, Dec 31, 2005 at 07:59:02AM +0300, Al Boldi wrote:
> > Alan Cox wrote:
> > > On Gwe, 2005-12-30 at 23:06 +0300, Al Boldi wrote:
> > > > > +3 - (NEW) paranoid overcommit The total address space commit
> > > > > + for the system is not permitted to exceed swap. The machine
> > > > > + will never kill a process accessing pages it has mapped
> > > > > + except due to a bug (ie report it!)
> > > >
> > > > This one isn't in 2.6, which is critical for a stable system.
> > >
> > > Actually it is
> > >
> > > In the 2.4 case we took "50% RAM + swap" as the safe sane world
> > > 'never OOM kill' and to all intents and purposes it works. We also had
> > > a 100% paranoia mode.
> > >
> > > When it was ported to 2.6 (not by me) whoever did it very sensibly
> > > made the percentage tunable and removed "mode 3" since its mode 2 0%
> > > ram and can be set that way.
> >
> > Only, doesn't this imply that you cannot control overcommit unless
> > backed by swap? i.e Without swap the kernel cannot use all of ram,
> > because it would overcommit no-matter what, thus invoking OOM-killer.
> >
> > Which raises an important question: What's overcommit to do with
> > limiting access to physical RAM?
>
> As shown in my previous mail, it allows malloc() to return NULL. I've
> also successfully verified that it allows mmap() to fail if there is
> not enough memory. I disabled swap, and set the overcommit_ratio to 95
> and could not kill the system. Above this, it becomes tricky. At 97, I
> see the last malloc() calls take a very long time, and at 98, the
> system still hangs. But 95% without swap seems stable here.
Thanks, for confirming this! And I agree that this patch and 2.6 offer an
important and necessary workaround to inhibit OOM-killer, but it's no more
than a workaround.
And so the question remains: Why should overcommit come into play at all
when dealing with physical RAM only?
Shouldn't it be possible to disable overcommit completely, thus giving kswapd
a break from running wild trying to find something to swap/page, which is
the reason why the system gets unstable going over 95% in your example.
Thanks!
--
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
