kostikbel at gmail.com
Fri Jan 4 06:19:08 PST 2008
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 <rwatson at 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.
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.
May be, time to revive it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20080104/a0a47064/attachment.pgp
More information about the freebsd-current