From: "Roger Heflin" <rheflin@atipa.com>
To: "'Alan Cox'" <alan@lxorguk.ukuu.org.uk>
Cc: "'Al Boldi'" <a1426z@gawab.com>, <linux-kernel@vger.kernel.org>
Subject: RE: Resource limits
Date: Mon, 26 Sep 2005 16:21:50 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AcXCuQR9PhB3L03GTDC5aLQ2u+raLQAAgZoQ
In-Reply-To: <1127754691.27757.26.camel@localhost.localdomain>
Message-ID: <EXCHG2003VnkB4ltFlm00000b18@EXCHG2003.microtech-ks.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1340
Lines: 40

 

> On Llu, 2005-09-26 at 09:44 -0500, Roger Heflin wrote:
> > While talking about limits, one of my customers report that if they 
> > set "ulimit -d" to be say 8GB, and then a program goes and
> 
> The kernel doesn't yet support rlimit64() - glibc does but it 
> emulates it best effort. Thats a good intro project for someone
> 
> > It would seem that the best thing to do would be to abort 
> on allocates 
> > that will by themselves exceed the limit.
> 
> 2.6 supports "no overcommit" modes.
> 
> Alan
> 

Ah.

So any limit over 4GB, is emulated through glibc which means the
fix would need to be in the emulation that is outside of the
kernel.

And I think they were setting the limit to more like 32 or 48GB,
and having single allocation's go over that.   Some of the machines
in question have 32GB of ram, others have 64GB of ram, both with
fair amounts of swap, and when the event happens they need to create
enough swap to get enough swap to process the request.

The overcommit thing may do what they want.

                              Thanks.
                              Roger

-
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/