Date: Fri, 04 Jan 2008 09:11:33 -0500 From: Skip Ford <skip@menantico.com> To: Kostik Belousov <kostikbel@gmail.com> Cc: Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= <des@des.no>, freebsd-current@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org>, Jason Evans <jasone@FreeBSD.org>, Poul-Henning Kamp <phk@FreeBSD.org> Subject: Re: sbrk(2) broken Message-ID: <20080104141133.GB788@menantico.com> In-Reply-To: <20080104135912.GB57756@deviant.kiev.zoral.com.ua> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <rwatson@FreeBSD.org> 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? > Oh, I thought that I was the sole user of the patch. What problems did you > encountered while testing it ? Nope, there are two of us. :-) I don't remember encountering problems. I never put it into production because maintaining it in a local branch was beyond my ability. I just didn't know enough to know what it did and didn't do, or how it would have to be modified to work with future changes. I just didn't understand it enough to go with it and maintain it. > 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. -- Skip
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080104141133.GB788>