From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 14:57:22 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 491DF16A418; Fri, 4 Jan 2008 14:57:22 +0000 (UTC) (envelope-from skip@menantico.com) Received: from vms040pub.verizon.net (vms040pub.verizon.net [206.46.252.40]) by mx1.freebsd.org (Postfix) with ESMTP id 2221F13C461; Fri, 4 Jan 2008 14:57:22 +0000 (UTC) (envelope-from skip@menantico.com) Received: from mx.menantico.com ([71.168.197.190]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JU400IOZK8YJB05@vms040.mailsrvcs.net>; Fri, 04 Jan 2008 08:58:10 -0600 (CST) Date: Fri, 04 Jan 2008 09:58:07 -0500 From: Skip Ford In-reply-to: <20080104141857.GC57756@deviant.kiev.zoral.com.ua> To: Kostik Belousov Mail-followup-to: Kostik Belousov , Robert Watson , Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= , freebsd-current@FreeBSD.org, Jason Evans , Poul-Henning Kamp Message-id: <20080104145807.GC788@menantico.com> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Content-transfer-encoding: 8BIT Content-disposition: inline References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86wsqqaqbe.fsf@ds4.des.no> <20080104110511.S77222@fledge.watson.org> <20080104135438.GA788@menantico.com> <20080104135912.GB57756@deviant.kiev.zoral.com.ua> <20080104141133.GB788@menantico.com> <20080104141857.GC57756@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= , freebsd-current@FreeBSD.org, Robert Watson , Jason Evans , Poul-Henning Kamp Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 14:57:22 -0000 Kostik Belousov wrote: > On Fri, Jan 04, 2008 at 09:11:33AM -0500, Skip Ford wrote: > > Kostik Belousov wrote: > > > On Fri, Jan 04, 2008 at 08:54:38AM -0500, Skip Ford wrote: > > > > Robert Watson wrote: > > > > > On Fri, 4 Jan 2008, Dag-Erling Smørgrav wrote: > > > > > >Robert Watson writes: > > > > > >>The right answer is presumably to introduce a new LIMIT_SWAP, which > > > > > >>limits the allocation of anonymous memory by processes, and size it to > > > > > >>something like 90% of swap space by default. > > > > > > > > > > > >Not a good solution on its own. You need a per-process limit as well, > > > > > >otherwise a malloc() bomb will still cause other processes to fail > > > > > >randomly. > > > > > > > > > > That was what I had in mind, the above should read RLIMIT_SWAP. > > > > > > > > Are you referring to the implementation of RLIMIT_SWAP in the > > > > overcommit-disable patch at: > > > > > > > > http://people.freebsd.org/~kib/overcommit/index.html > > > > > > > > ...or some other as yet unwritten implementation? That patch doesn't > > > > currently do 90% of swap but easily can. That's been available for almost 3 > > > > years now. I tested it at one point but not lately and it never went into > > > > production. Do you, and others, have a problem with that implementation? > > > > > What you mean by "do 90% of swap" ? > > > > I was referring only to what Robert said above, that he thinks RLIMIT_SWAP > > should limit anon memory size to ~90% of swap by default. Your patch, > > last I looked, limits it to 100% of swap by design but could be easily > > changed I think. > > Ok. The patch really imposes two kind of limits: > - the total amount of anon memory that could be allocated in the whole > system (this is what I called "disabling overcommit") > - per-user RLIMIT_SWAP limit, that account the allocation by the uid. This > has some obvious problems with setuid(2) syscall. AFAIR, I ended up > not moving the accounted numbers to the new uid. > > Both limits can be turned on/off independently. Independently, but using the same sysctl knob which seems a bit awkward. > May be, time to revive it. The concensus in this thread seems to be that a per-process limit needs to be implemented rather than, or in addition to, the per-uid limit you already have. -- Skip