From owner-freebsd-arch@FreeBSD.ORG  Fri Oct 12 22:15:44 2012
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
 by hub.freebsd.org (Postfix) with ESMTP id 7762DF9F;
 Fri, 12 Oct 2012 22:15:44 +0000 (UTC) (envelope-from jilles@stack.nl)
Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107])
 by mx1.freebsd.org (Postfix) with ESMTP id 104FE8FC0A;
 Fri, 12 Oct 2012 22:15:43 +0000 (UTC)
Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131])
 by mx1.stack.nl (Postfix) with ESMTP id 942561203C1;
 Sat, 13 Oct 2012 00:15:38 +0200 (CEST)
Received: by snail.stack.nl (Postfix, from userid 1677)
 id 7EFCD2848C; Sat, 13 Oct 2012 00:15:38 +0200 (CEST)
Date: Sat, 13 Oct 2012 00:15:38 +0200
From: Jilles Tjoelker <jilles@stack.nl>
To: John Baldwin <jhb@freebsd.org>
Subject: Re: mmap and resource limits
Message-ID: <20121012221538.GA96422@stack.nl>
References: <83AE27A6-C844-4720-99E7-A12106F77227@xcllnt.net>
 <FD8885CC-6E66-435A-A858-82F41B0F239D@xcllnt.net>
 <201210121338.28956.jhb@freebsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201210121338.28956.jhb@freebsd.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Marcel Moolenaar <marcel@xcllnt.net>, freebsd-arch@freebsd.org
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Oct 2012 22:15:44 -0000

On Fri, Oct 12, 2012 at 01:38:28PM -0400, John Baldwin wrote:
> On Friday, October 12, 2012 12:04:19 pm Marcel Moolenaar wrote:

> > On Oct 8, 2012, at 10:40 AM, Marcel Moolenaar <marcel@xcllnt.net> wrote:

> > > What's the progress of mmap(2) doing resource accounting and
> > > it respecting resource limits?

> > *silence*

> > Ok, so no new progress. We're still not doing it and we don't
> > have an idea of how we want to do it if or when we're going to
> > want to do it. Consequently: we still need brk()/sbrk().

> > Correct assessment?

> Well.  You can use RLIMIT_AS, but that includes anything you map, not
> just malloc().

This is effective for many applications. I have found it particularly
useful against runaway memory leaks in applications moved from 32-bit to
64-bit systems.

> The problem is that even if you use sbrk() and rely on RLIMIT_DATA,
> any misbehaving app can just use mmap(MAP_ANON) or shm_open() to get
> around that.

As of 8.0 it is possible to enable swap accounting to limit anonymous
memory. This uses the vm.overcommit sysctl and RLIMIT_SWAP rlimit
described in tuning(7). For example:

# sysctl vm.overcommit=2
$ ulimit -w 100000

The rlimit limits the total for the UID (much like RLIMIT_NPROC,
RLIMIT_SBSIZE and RLIMIT_NPTS).

-- 
Jilles Tjoelker